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LANGUAGE  FOR  A DESIGN  INFORMATION  SYSTEM 
by  Charles  Eastman  and  Max  Henrion 
PART  ONE:  INTRODUCTION 

The  authors  are  part  of  a group  in  the  Computer  Science  Department  and 
the  Institute  of  Physical  Planning  at  Carnegie-Mellon  University,  which  is 
developing  a computerised  information  system  for  designing  large  physical 
systems.  The  information  system  is  expected  to  be  useful  in  the  design  of 
buildings,  ships,  mechanical  components  and  other  entities  that  normally  require 
drawings,  specifications  and  a large  number  of  documents  for  their  description 
and  that  must  respond  to  a range  of  diverse  analyses.  Its  purpose  is  to  allow  a 
physical  system  to  be  represented  within  a computer  by  a single  integrated 
database  in  sufficient  detail  for  design  and  construction.  It  incorporates 
compact  data  structures  for  representing  both  three-  dimensional  and  other  kinds 
of  information.  Descriptions  of  these  datastructures  have  been  presented 
elsewhere  [2], [3]. 

1.  OBJECTIVES 

The  following  are  some  desiderata  for  such  a design  information  system. 

A user  should  be  able  to  define,  inspect,  modify  and  analyze  different  designs,  r- 
and  these  operations  should  be  executable  in  a natural  and  convenient  manner. 
High-level  extensions  to  the  system  should  be  possible  for  such  purposes  as 
automatic  detailing,  selection  and  layout  of  parts,  analysis  and  evaluation. 
Both  interactive  use  and  the  application  of  large,  pre-defined  programs  should 
be  allowed.  It  may  be  desirable  to  interface  the  integrated  database  with 
external  analysis  packages,  which  will  involve  selection  and  reformatting  of 
data.  In  addition,  it  should  facilitate  convenient  output,  in  such  forms  as 
engineering  drawings,  parts  lists  and  the  results  of  analyses.  Many  of  these 
requirements  may  be  unique  to  particular  design  professions  or  organizations, 
and  such  facilities  will  have  to  be  capable  of  being  tailored  to  a variety  of 
professions  and  organizational  environments. 

These  operations  have  been  conveniently  organized  as  a high  level 
computer  language.  The  objective  of  this  language  is  to  allow  the  user  to 
easily  perform  the  operations  required  to  design  within  the  computer  database. 

In  this  sense,  it  is  a LANGUAGE  FOR  DESIGNING.  We  have  developed  and  are 
implementing  such  a language,  named  GLIDE  (Graphical  Language  for  Interactive 
DEsign).  In  this  paper,  we  describe  the  semantics  and  associated  syntax  of  this 
language. 

The  basic  unit  of  information  within  GLIDE  is  an  ELEMENT,  defined  as  a 
set  of  attributes  describing  some  coherent  entity.  An  Element  may  be  a building 
component,  a space  or  activity  area,  building  subsystem,  or  any  other  entity 
relevant  to  design.  ATTRIBUTES  are  properties  of  an  Element,  including  both 
spatial  Ones,  such  as  location  and  shape,  and  others  such  as  weight,  material, 
surface  and  color.  In  GLIDE,  a shape  is  defined  as  a planar  polyhedron. 
Attributes  may  also  represent  relationships  between  the  referent  and  one  or  more 
other  Elements.  Some  attributes  are  system  defined  and  maintained  while  others 
can  be  defined  and  manipulated  by  the  user, 
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Many  design  components  are  standard  units  and  described  in  catalogs. 
Many  abstract  entities,  such  as  activity  areas  in  building  design,  are  also  well 
defined  and  available  from  handbooks.  All  such  standard  information  used  in 
design  should  be  accessible  from  stored  catalogs.  Other  elements  are  ur.ique  and 
defined  by  a designer.  There  should  be  convenient  graphical  means  to  enter  such 
information  into  the  system. 

As  elements  are  included,  they  are  arranged  in  spatial  relationships. 
It  is  often  desirable  to  operate  on  a whole  collection  of  elements  as  a unit.  A 
language  for  design  should  allow  the  formation  of  sets  of  elements  and 
operations  on  those  sets. 

Design  tasks  vary  from  the  very  repetitive  generation  of  standardized 
plans  to  the  creative  and  sometimes  idiosyncratic  development  of  solutions  to 
unique  problems.  The  full  set  of  objectives  involved  in  a design  are  rarely 
achieved  on  the  first  pass.  Several  iterations  are  usually  required,  some  for 
exploring  alternative  configurations,  and  others  for  considering  alternative 
objectives,  which  often  change  as  the  design  evolves.  Moreover,  a completely 
detailed  description  of  the  sub-systems  making  up  a design  is  often  not 
available  at  the  start.  Rather,  the  properties  of  the  various  subsystems  are 
defined  incrementally,  in  a particular  evolutionary  sequence.  This  might  be 
called  a DESIGN  SEQUENCE.  Most  CAD  systems  developed  to  date  incorporate  a 
rigid  design  sequence,  which  is  effective  for  only  a very  limited  range  of 
conventionalized  results.  A language  for  design  should  be  able  to  accommodate  a 
range  of  different  kinds  of  design  sequences  reflecting  different  styles  of 
problem  solving. 

In  summary,  then,  a language  for  design  must  minimally  support: 

1.  The  selection  of  elements  from  a catalog, 

2.  The  graphical  definition  of  custom  elements, 

3.  The  placement  and  grouping  of  elements,  individually  or  in  sets. 

4.  Visual  inspection  of  a design,  in  perspective,  orthographic,  or 
schematic  representations. 

5.  Procedures  for  analysis  and  evaluation  of  a design,  eg.  structural, 
acoustical,  thermal, etc.,  either  as  packages  within  the  language 
or  by  providing  interfaces  for  passing  the  required  data  to  existing 
analysis  programs. 

6.  Evaluation  of  the  internal  consistency  of  a design,  with  regard 
spatial  conflicts,  joining  conditions,etc. 

7.  Alternative  top-down,  bottom-up  or  other  evolutionary  sequences 
of  design. 

Some  other  requirements  will  be  introduced  as  we  proceed. 
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2.  LEVEL  OF  THE  LANGUAGE 

The  development  of  a computer  language  for  design  has  no  heritage  on 
which  to  stand.  It  is  generally  agreed  that  there  is  no  natural  language  of 
design  currently  in  widespread  use,  in  contrast  to,  say,  medicine  or  law.  It 
seems  doubtful  that  any  one  set  of  high  level  structures  and  operations  could  be 
defined  that,  alone,  would  be  sufficient  for  a general  range  of  applications. 

The  alternative  is  to  provide  a set  of  basic  commands,  plus  general 
language  features,  to  allow  the  definition  of  higher  level  commands  for 
particular  applications.  These  facilities  should  provide  an  environment  in 
which  a design  organization  can  easily  develop  software  to  support  its  own 
particular  design  sequences  and  methods.  Thus  the  language  should  consist  of  a 
set  of  basic  commands  for  conveniently  creating,  displayirtg  and  modifying  design 
Elements  with  powerful  features  for  dealing  with  geometric  properties.  In 
addition  it  should  contain  general  control  structures  and  means  for  defining  new 
procedures  and  record  formats,  which  can  be  used  to  extend  the  basic  set  of 
operations  and  data  structures. 

The  user  of  the  command  language  and  its  extensions  would  be  a designer, 
architect  or  other  person  without  programming  expertise.  However  the  user  of 
the  complete  language,  who  will  write  these  extensions,  would  probably  be  a 
specialist  applications  programmer.  In  practice  there  need  be  no  hard  dividing 
line  between  these  two  levels  of  GLIDE  and  learning  of  the  complete  language 
should  be  feasible  in  small  incremental  steps  from  the  simpler  sub-language. 

For  direct  interaction  with  the  database  the  operating  environment 
should  be  interpretive,  ie  commands  should  be  translated  and  executed  as  they 
are  entered  line  by  line.  But  for  efficient  execution  of  pre-defined  procedures 
it  is  desirable  that  they  are  compiled  once  only,  at  the  time  they  are  defined. 
It  is  important  that  such  pre-compiled  procedures  be  independent  of  the 
particular  state  of  the  database  at  compilation  time,  so  that  their  validity 
cannot  be  affected  by  any  changes  to  it.  Hence  it  must  be  possible  to  delay 
binding  or  linking  of  procedures  to  other  procedures  and  entities  in  the 
database  until  execution. 


3.  ISSUES  OF  IMPLEMENTATION 

Large  database  systems  can  be  implemented  in  two  basically  different 
ways:  as  an  extension  to  an  existing  language,  such  as  FORTRAN,  or  sc  an 

independent  but  complete  language  unto  itself.  GLIDE  places  heavy  emphasis  on 
the  manipulation  of  new,  large,  system  defined  records  and  the  operations  on 
these  records  were  among  the  major  concerns  of  the  language  design.  Graphical 
interaction  is  to  be  the  major  form  of  interaction  and  extensions  are  required 
for  even  this  type  of  input-output.  GLIDE  is  also  oriented  toward  mini-computer 
implementation.  The  range  of  high  level  languages  to  extend  was  thus  quite 
limited.  Probably  most  persuasive,  however,  was  the  recognition  that  GLIDE  is  a 
research  vehicle,  in  which  we  expect  to  study  the  operators  and  syntax  most 
desireable  for  developing  high  level  design  applications.  Restrictions  on  the 
style  of  language,  imposed  from  the  base  language  adopted,  would  inhibit  work 
toward  this  objective.  For  these  reasons,  we  chose  to  implement  GLIDE  as  an 
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essentially  new  language.  This,  however,  did  not  preclude  us  from  adopting  a 
standard  Algol-like  syntax  where  appropriate. 

A mojor  feature  of  GLIDE  is  its  focus  on  spatial  information  and  its 
reliance  on  interactive  graphic  techniques  for  editing  it.  In  the  language 
definition,  however,  we  have  taken  a conservative  stance  toward  graphical 
operations  and  have  defined  only  the  minimal  level  needed  for  this  end.  They 
are  easily  implemented  in  direct  view  storage  tube  terminals.  Later,  we  may 
propose  extensions  that  will  provide  more  powerful  graphical  operations. 

GLIDE  utilizes  the  spatial  information  record  scheme  developed  in 
BDS[2],[3].  That  is,  ^t  stores  shape  topologies  separately  from  geometries  and 
requires  a shape  to  reference  a topology  by  name.  Topologies  can  be  created 
by  using  special  operators,  as  well  as  convenient  graphical  methods.  Other 
spatial  representations  are  compatible  with  GLIDE,  however,  and  we  have 
attempted  to  provide  a syntax  and  set  of  commands  that  are  inclusive  of  a 
range  of  spatial  representations.  Shapes  are  manipulated  using  the  spatial 
union,  intersection  and  complement  operations. 

A.  METHODS  OF  REPRESENTATION 


An  important  question  in  designing  representations  is  whether  the 
information  should  be  embedded  in  procedures  in  implicit  form  rather  than  be 
represented  as  explicit  data.  A procedural  representation  requires  less  storage 
space,  but  at  the  cost  of  extra  computation  every  time  the  data  is  required. 
This  compute  versus  store  question  is  not  a dichotomous  choice  but  a gradation 
of  possible  trade-offs.  The  best  solution  for  a particular  application  depends 
on  both  the  computing  resources  available  and  the  actual  demands  upon  the 
system. 

At  one  level  this  trade-off  is  a question  of  the  database  implementation 
and  is  more  or  less  independent  of  the  language  design.  For  example,  in  BOS  the 
vertices  of  each  shape  (Form)  are  stored  only  once,  and  the  actual  co-ordinates 
of  each  instance  (Copy)  in  space  are  computed  only  when  needed.  This  and  other 
decisions  were  taken  to  optimize  available  computing  resources,  on  the  basis  of 
an  analysis  of  expected  demands[I].  However  GLIDE  could  well  be  implemented 
with  a quite  different  database  organisation. 

At  a higher  level  each  segment  of  Glide  code  constitutes  a procedural 
representation  of  some  information.  In  general,  source  code  is  the  most  compact 
way  of  representing  a database.  We  anticipate  that  a catalog  of  design  elements 
will  be  built  up  as  a library  of  procedures.  In  an  interpretive  environment  it 
is  up  to  the  user  to  control  when  a procedure  should  be  converted  into  explicit 
data  and  how  long  this  structure  should  be  retained.  Some  features  of  the 
language  aid  in  this  task.  Any  records  declared  locally  within  a procedure  are 
automatically  deleted  at  the  end  of  execution.  Thus  the  information  is 
incarnated  only  for  the  duration  of  execution  of  the  procedure.  Alternatively 
the  new  records  may  be  declared  as  global  within  the  procedure,  in  which  case 
they  persist  in  the  database  until  they  are  deliberately  deleted.  Any  further 
calls  to  that  procedure  do  not  have  to  recreate  the  records  but  can  use  the 
pre-existing  definitions.  For  many  practical  purposes,  such  as  detecting 
spatial  conflicts  between  objects,  a procedural  representation  would  be  very 
unwieldy  for  large  databases.  Therefore  we  anticipate  that  during  interactive 
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design  the  primary  method  of  representation  will  be  as  explicit  data. 


5.  SYNTACTIC  STYLE 

Before  we  go  on  to  describe  a particular  instantiation  of  these  language 
features,  some  general  issues  affecting  the  structure  and  syntax  of  the  language 
should  be  mentioned.  While  the  selection  of  many  semantic  features  flows  fairly 
directly  from  the  needs  of  a design  information  system,  the  choice  of  syntactic 
forms  will  tend  to  be  more  controversial.  It  seems  evident  that  syntax  affects 
the  ease  of  learning  and  of  use  of  a language,  especially  for  users  with  little 
or  no  programming  experience.  For  more  discussion  of  these  issues  see  Wirth 
[4].  One  day  experimental  evidence  of  the  relative  merits  of  syntactic  features 
may  be  obtained  by  comparison  of  alternative  implementations.  Meanwhile  the 
priorities  to  be  awarded  to  these  criteria  must  be  based  on  conjectures  about 
future  use  and  users  and  the  relative  efficiency  of  alternative  implementations. 

GLIDE  syntax  reflects  the  twin  objectives  of  providing  both  a simple 
command  language  and  a more  general  language,  with  features  allowing 
extensibility.  For  the  first  objective,  procedures  may  be  called  with  a 
"command-style"  syntax;  that  is,  the  arguments  need  not  be  enclosed  in 
parentheses  and  alphanumeric  mnemonics  may  be  used  as  separators  instead  of 
commas.  The  more  conventional  function  notation  calling  syntax  may  also  be  used 
when  preferred.  Frequently  used  constructions  such  as  those  for  defining  a 
location  and  orientation  in  space,  or  the  co-ordinates  of  a shape  vertex,  have 
special  concise  forms  with  convenient  defaults.  It  also  happens  that  the 
reduction  of  redundancy  in  the  database,  especially  with  regard  to  spatial 
information,  encourages  conciseness  in  the  linguistic  forms  for  entering  the 
information,  and  vice  versa.  Thus  the  task  of  entering  spatial  information  is 
much  eased,  and  of  course  it  can  be  further  eased  by  the  use  graphic  techniques. 

The  full  language  incorporates  the  usual  features  for  control  structures 
and  definition  of  procedures.  For  these  we  have  adopted  an  Algol-based  syntax, 
with  standard  block  structure.  We  have  followed  the  precepts  of  structured 
programming.  GO  TOs  are  not  provided.  GLIDE  is  expression-oriented.  That  is, 
most  statements  return  a value  and  can  be  treated  as  expressions.  For  example 
BEGIN  END  blocks  return  the  value  of  their  last  statement. 


In  addition  to  the  simple  data  types  - number,  boolean  and  text  - GLIDE 
has  a number  of  record  types  which  provide  special  structures  for  representing 
element  information.  These  include  TOPOLOGY  as  mentioned  above,  FORM  which 
defines  a class  of  elements  and  is  akin  to  a user-defined  record  format,  COPY, 
being  an  instance  of  a Form,  and  SET,  being  a group  of  elements.  As  in  ALGOL, 
all  identifiers  must  be  declared  and  their  type  specified  before  they  can  be 
used.  In  most  cases  the  data  type  of  an  operand  or  argument  is  determined  by 
iis  context  and  can  be  checked  at  compilation.  Block  structure  allows  dynamic 
declarations  and  allocation  of  memory  during  execution,  as  in  Algol  or  PL/1. 

Since  a prime  objective  is  the  creation  of  new  entities  forming  a 
database,  there  is  particular  emphasis  on  declaration  features.  Notably,  global 
records  can  be  created  from  within  inner  blocks  including  from  inside 
procedures.  Correspondingly,  deletions  are  also  allowed. 
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6.  CONCLUSIONS 

The  second  part  of  the  paper  gives  a preliminary  description  of  a 
language  which  attempts  to  fulfill  the  requirements  outlined  above.  In  the 
third  section  we  present  some  example  programs,  with  which  we  have  attempted 
to  indicate  the  kinds  of  design  operations  easily  defined  within  GLIDE.  The  full 
extent  of  the  strengths  and  weaknesses  of  the  language  will  only  be  known  after 
extensive  experience  with  it  and  other  design  oriented  languages. 

This  work  was  funded  by  the  National  Science  Foundation.  We  have 
received  many  useful  suggestions  throughout  the  development  of  this  work  from 
many  collegues  in  architecture  and  computer  science,  especially  Adrian  Baer, 
Gilles  Lafue,  Joseph  Lividini  and  Bob  Kenyon. 
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PART  rwr);  A ';P(CITICATK<r4  f <TR  Gl  |D€ 

1  fdmdami.mtai  s 

1.1  OPFRATING  irwiRorif-lIMI 

Thr  operatinp  pnv«rpf’'»H'nf  lor  Gl«1p  !'■  '■.p'pi  infp^prpttvc.  In  general, 
each  '.fatenient  typed  into  ti'e  ty*tf»n  n tmm««rti;»fply  tran'-laled  and  eKeculed.  It 
al'-.o  possible  to  cp"‘bine  » numner  ot  statements  into  a single  block-statement 
enclosed  between  M*  f'.K J an<j  ft£}  )n  tnis  case  trans'ation,  and  therefore 
sy  111  an -c  bee  king,  ta^es  place  staien.ent  by  'tatemenl,  but  enecution  is  delayed 
until  the  FMD  of  the  block  After  eac*i  lirse  tne  «.y«.terr  responds  with  a prompt 
c bai  ac  tei  and  a runiber  ot  tabs  eoua  to  ti'e  depth  ot  block  nesting,  providing 
aiitomatic  indentation  ret  eci  eg  blocs  strixtu'e. 

Programs  to  be  stored  and  repeatedly  are  defined  as  procedures. 

Tbry  are  compiled  as  lliey  are  first  entered  into  the  system,  statement  by 
staternent,  with  Ibr*  resuiln.s  ».,r>iai  ctecK  A rrulme  library  contains 
pirdofinrd  procedures  lor  'aiiou'  da’a-base  ’•'anipulations  and  standard  design 
operations  It  can  also  conia  n rout -'es  to  create  standard  design  ’.omponents 
U lempiits)  and  thus  serve  as  a parts  catalog 


1.2  UXEMES 

Ibnie  are  tour  kind'  cl  lereme  or  terminal  symbol; 

1 Gperial  syr’ta«  ' v mbols,  si,-h  ts‘»(]ft«,:,  each  being 
a single  non- alpbanumeric  ebarartr  Listed  in  appendnr  3 

2 Keywords  such  as  111  GIN  EflO  FOR  IF  Listed  in  appendix  3. 

3 I iteral  niiiiibe's,  both  integer  and  real  See  section  2.1. 

A LIser  declared  names  or  identifiers. 

L’ .or -declared  names  consist  ot  a letter  or  "J"  followed  by  zero  or  more 
lotterSi  digits,  ""  or  Only  bie  first  31  characters  of  a name  are 

significant.  Upper  and  lower  ca^e  letters  are  treated  as  equivalent  throughout. 

Successive  alphanurnenc  le«emes  must  be  seperaled  by  a space,  tab  or 
new-line,  and  so  these  chararters  cannot  occur  within  them  Beyond  this,  space, 
tab  and  new -line  can  be  used  freely  anywhere  in  Glide  code  and  are  ignored  by 
the  interpreter, 

NB  <n>  denotes  examples  of  Glicic  cede  here  and  subsequently. 

. Legal  names: 

A,  PDPl  1,  U.S.A.,  C.mmp,  Spiral. staircase  lb, 
etc . SMrIlon 
Illegal  names: 

.NAME,  Ad,  Go  away,  POP  - 1 0 

letter  ;;=  Ajd|C|  |Z|a|b|c |...|z|S 
digit  ::=  l(2|3|A|b|6|7(3iT|0 

j name  ::=  letter  | name  letter  | name  digit  | name  . 
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NB:  See  appendix  1 for  details  of  the  BNF  conventions  used. 


1.3  DATA  TYPES 

All  variables  and  expressions  are  o'  a particular  data  type.  Variable 
names  must  have  their  type  declared  before  they  can  be  used.  In  most  cases  the 
context  in  which  a variable  occurs  in  a statement  determines  what  type  it  should 
be  and  the  interpreter  will  automatically  check  that  it  is  correct. 

There  are  three  simple  data  types  - Real,  Boolean  ^nd  Text.  They 
consist  of  a single  value,  in  contrast  to  records  which  can  contain  several 
simple  values  or  other  sub-records.  Record  types  include  Topology,  Form, 
CopySet  and  View.  Vectors,  or  1 -dimensional  arrays  also  are  provided,  but  can 
only  be  of  simple  types. 

ELEMENTS  in  the  data-base  represent  such  things  as  physical  objects  and 
spaces.  An  Element  consists  of  a set  of  ATTRIBLITES,  which  may  include  both 
user-defined  Attributes  of  the  above  data  types,  and  some  system-structured 
Attributes  such  as  SHAPE  and  LOCATION.  FORMS  are  exemplars  or  prototypes  for 
a class  of  similar  Elements.  All  Elements  in  such  a class  are  COPIES  of  the  Form 
from  which  they  are  derived.  Forms  may  also  be  considered  as  user-defined 
record  types,  of  which  Copies  are  instantiations.  SETS  are  collections  of 
Elements.  ITEMS  are  reference  va'’iablcs  which  refer  to  Elements  and  Sets. 
TOPOLOGIES  are  used  to  help  define  the  Shape  Attribute  of  Forms.  The  names  of 
these  four  record  types  are  bound  to  their  referents  at  definition,  and  the 
binding  is  fixed  for  as  long  as  they  exist.  Such  names  are  constants  rather 
than  variables.  Therefore  two  additional  types  are  provided  which  are  reference 
variables;  ELEMENT  refers  to  Copies  and  ITEKi  can  refer  to  Copies  or  Sets. 

In  addition  the  Geometric  types  - FACE,  EDGE  and  VERTEX  - are  parts  of  a 
Shape.  The  exact  nature  and  use  of  all  these  types  will  be  described  later. 

simple-type  ;:=  REAL  ( BOOL  | TEXT 
record-type  ;:=  TOPO  | FORM  | ITEM  | SET  | VIEW 
geom-type  FACE  | EDGE  | VERTEX 
type  ::=  simple-type  | record-type 

lA  STATEMENTS  AND  EXPRESSIONS 

GLIDE  is  an  expression  oriented  lar-ua;:'’.  Most  statements  evaluate  to  a 
particular  value  of  known  type.  The  typo  and  value  of  the  different  kinds  of 
statement  will  be  defined  as  we  proceed.  Conversely  expressions,  such  as 
arithmetic  expressions  or  record  definitions,  ^an  be  considered  as  statements  in 
many  contexts.  There  are  six  basic  kinds  of  statements  in  addition  to 
expressions  - control  statements,  procedure  calls,  assignments,  comments, 
declarations  and  blocks.  Expressions  will  be  described  under  headings  for  their 
type.  The  control  statements,  including  the  conventional  c anditional  and  loop 
statements  are  described  in  section  6.  The  remaining  kinds  of  statement  ate 
described  below. 
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Infix  operators  are  defined  for  various  data  types,  including  the 
arithmetic  operators  boolean  connectives,  assignment  («-)  and  others. 

The  full  precedence  hierarchy  for  all  infix  operators  is  given  in  full  in 
Appendix  2.  Higher  precedence  means  those  operators  are  evaluated  first.  Equal 
precedence  operators  are  evaluated  from  left  to  right.  The  system  precedence 
ordering  can  always  be  overridden  by  putting  parentheses  around  those 
subexpressions  which  are  to  be  evaluated  first. 

statement  expression  | control-statement  | proced-call 
1 assignment  | comment  1 block  1 declaration 
expression  ::=  n | bool  | text  | topo  | form  | elem  | item 
I set  I view  1 "(’’expression")" 


l.A.l  PRCXEOURE  CALLS 

Procedure  calls  can  use  standard  function  syntax,  with  the  procedure 
name  followed  by  arguments,  which  are  enclosed  in  parentheses  and  separated 
by  commas.  It  is  also  permissable  to  omit  the  parentheses.  Where  they  have  been 
declared,  alphanumeric  symbols  may  be  used  as  seperators  instead  of  commas. 
This  allows  a "command-style"  syntax,  which  may  be  easier  for  non-specialist 
users. 


<> 

lNVERT(a,b,c) 

SIM(x) 

ALIGN  a WITH  b ALONG  x 

REPEAT  beam  BETWEEN  xl,yl,zl  TO  x2,y2,z2  TIMES  10 

proced-call  = proced-id  [(  arg  {sep  arg}  )] 

1 proced-id  [arg  {sep  arg}] 

arg  = expr 
sep  = name  | , 


1.A.2  ASSIGNMENT 

The  operator  assigns  the  value  of  an  expression  into  the-  variable, 
which  may  be  a simple  lype  or  item  variable.  The  expression  to  be  assigned  is 
chocked  for  type  compatibility  with  the  variable  to  which  it  is  assigned.  Note 
that  since  record  names  are  fixed  names  and  not  variable  it  is  meaningless  (and 
illegal)  to  assign  to  them.  The  value  of  an  assignment  statement  is  the  right 
operand.  Thus  assignments  may  be  chained: 


A*-Br-Cr-0j 


assignment  :;=  num-id[index]  ♦-  n | bool-id[inclex]  ♦-  bool 

I text-id[inclex]  •-  text  | item-id  ♦-  item  | elem-id  ♦-  elem 
index  ’’["  n ’’]’’ 
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1.4.3  COMMENTS 

Syntactically,  comments  are  statements  which  start  with  "!".  They  may 
contain  any  character  except  since  this  terminates  them.  They  are  ignored 
by  the  interpreter. 

comment  ! any-chars-except-j 

1.4.4  BLOCKS 

Blocks  consist  of  a sequence  of  statements  separated  by  ";"s  and 
enclosed  between  BEGIN  and  END.  Since  a block  is  also  a statement,  this 
definition  is  recursive  and  allows  blocks  to  be  nested  inside  one  another. 

A block  can  also  be  treated  as  an  expression  and  it  has  the  value  and 
type  of  the  last  statement  in  it. 

block  BEGIN  statement  {:  statement  ) END 

1.4.5  BASIC  DECLARATIONS 

All  names  (identifiers)  must  have  their  type  declared  before  they  can  be 
used.  The  general  format  for  declarations  is  the  type  followed  by  a list  of 
names  seperated  by  commas.  When  a record  name  is  declared  it  may  be  bound  to 
a definition  in  the  same  statement  using  the  operator  Basic  declarations 

return  no  value,  but  declarations  binding  a name  to  a record  definition  have 
that  new  record  as  value  and  type. 

oREAL  x,y,z; 

ITEM  top, bottom,  side.piece; 

SET  boxes  = {matchbox[l];  shoebox[3];  glpvebox[2]  } 

basic-decin  simple-decin  | record-dedn 

simple-decin  simple-type  name  {.name) 

array-decin  simple-type  VECTOR  name  [size]  {,name[size]} 

size  :i=  "["  n 

record-decin  ::=  record-type  name  {.name) 
record-binding  TOPO  name  = topo  | FORM  name  “ form 
I SET  name  = set  | VIEW  name  » view 


1.5  BLOCK  STRUCTURE  AND  THE  SCOPE  OF  NAMES 

As  in  Algol  60  and  its  derivatives,  programs  in  Glide  have  a block 
structure  which  defines  a hierarchy  of  scopes  for  local  variables  declared 
within  them.  Unless  specifically  indicated  otherwise,  variables  are  local  to 
the  block  in  which  they  are  declared.  This  includes  simple,  vector  and 
reference  variables,  but  not  record  names,  which  are  always  global  wherever  they 
are  declared.  For  local  declarations,  the  scope  within  which  an/  name  may  be 
referenced  is  limited  to  the  block  in  which  it  was  declared  and  any  sub-blocks 
it  may  contain.  Two  variables  with  the  same  name  may  be  declared  at  different 
block  levels.  In  that  case  the  name  is  assumed  to  refer  to  the  variable 
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declared  at  the  innermost  block  level  in  whose  scope  it  occurs. 

An  entire  design  project  may  last  over  many  sessions  at  the  terminal. 
Conceptually  the  scope  of  a project  corresponds  with  the  outermost  block  level. 
This  outer  block  begins  at  the  initiation  of  a project  and  is  the  outer  block 
level  during  a terminal  session.  Therefore  variables  and  entities  declared  at 
this  top  level  are  essentially  GLOBAL  and  continue  to  exist  between  sessions 
over  the  length  of  the  project. 

Record  names  have  global  scope  no  matter  where  they  are  declared 
starting  from  the  time  at  which  their  declaration  is  first  executed.  Records 
defined  in  this  way  persist  as  a permanent  part  of  the  database  unless  they  are 
explicitly  deleted.  Nevertheless  it  is  also  possible  to  create  temporary 
records  if  they  are  not  given  a fixed  name  but  created  within  a set  or  assigned 
to  a reference  variable.  In  this  case  their  scope  is  that  of  fheir 
longest-lived  reference.  This  allows,  for  example,  procedural  representations 
of  objects,  which  have  only  temporary  existence  as  data  during  the  execution  of 
the  procedures. 

Procedures  are  compiled  when  they  are  defined,  but  may  be  executed  much 
later.  Thus  compilation  should  be  independent  of  any  particular  globals  in  the 
data  base.  the  linking  of  references  within  the  procedure  to  pre-existing 
globals  IS  done  at  run-time.  All  such  globals  mentioned  must  be  previously 
declared  within  the  procedure  as  external.  Such  declarations  are  introduced  by 
the  keyword  GET. 

So  far,  with  the  exception  of  the  interpretive  environment,  we  have 
described  the  conventional  scope  hierarchy.  But  Glide  also  contains  some 
additional  features: 

1 Declarations  are  not  restricted  to  occurring  at  the  beginning  of  a 
block  but  may  occur  wherever  a statement  may  occur. 

2 Global  declarations  of  variables  also  can  occur  at  inside  block 
levels.  This  is  indicated  by  using  the  keyword  GLOBAL  before  the  declaration. 
In  the  case  that  a record  name  of  a variable  declared  as  global  has  been 
previously  similarly  declared,  then  the  current  declaration  is  treated  as  an 
external  declaration.  That  is  the  existing  name  and  any  value  or  definition  it 
may  have  is  linked  to  the  current  segment  of  code  at  execution  time.  If  the 
current  declaration  is  of  a record  type  with  a binding  to  a definition,  this  new 
definition  is  ignored.  This  feature  allows  procedures  to  create  Global  records 
fliey  may  need  the  first  time  they  are  called,  and  then  use  them  on  subsequent 
calls  without  having  to  recreate  tliem.  In  this  way  it  is  similar  to  the  own 
variable  concept,  but  it  can  be  accessed  from  outside  the  block  in  which  it  was 
declared,  after  the  first  execution  of  thal  procedure. 

3 The  scope  of  variables  can  be  limited  within  their  natural  scope  by 
deleting  them  explicitly  with  the  DELETE  command.  This  is  particularly  useful 
for  rrmovirig  globals  tirat  arc  no  longer  required. 


It  should  he  noted  that  GET,  GLOBAL  and  DflETE  sfatemenfs  a-e  all 
pypfiifpf)  at  run-time  and  hence  they  can  have  no  effect  on  the  data-base  at 
compilation. 
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<>SET  DRAINS  = { pipe[  1.3.5];  drain[l  TO  15]} 

GET  FORM  free,  bush;  GET  ATTRIB  TEXT  color,  density;  j 

DELETE  west. wing,  east. wing,  plumbing;  i 

• ! 

declaration  basic-decin  | attrib-decln  | record-binding  | ' ‘’i 

global-decin  | external-decln  | deletion 

global-decin  ;:•=  GLOBAL  basic-decin  | record-binding 

deletion  DELETE  name  {,  name} 

external-decln  ::«=  GET  basic-decin  | extet n-proced-decln 
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2 SIMPLE  TYPES 
2.1  NUMBERS 

All  numbers  are  treated  as  real  (floating  point),  although  both  integer 
and  real  syntax  is  acceptable  for  constants  (literals).  Numerical  expressions 

are  created  using  the  usual  arithmetic  operators:  addition,  subtraction, 

multiplication,  division  and  exponentiation.  (+  - * / T).  T has  highest 
precedence,  above  * and  / , which  are  above  + and  - . 

<>  REAL  x,y,z;  z^-125.2+100/(aT2-bt2); 

n ;;=  num-id[index]  | attribute  | proced-call 

I number-literal  | num-expr  | statement 
num  expr  ::=  n arith-op  n | ( n ) 
arith-op  *|/|-J+|f 

integer-literal  ::=-  digitjdigit) 

real-literal  ;:=  [integer-literal]  . integer-literal 

number-literal  [-jreal-literal  | [-Jinteger-literal 


I 


2.2  BOOLEANS 

Iho  bonlean  constants  (literals)  are  simply  TRUE  and  FALSE.  The 
relation  operators  compute  boolean  values  from  pairs  of  numbers.  The  boolean 
operator AND  and  OR  compute  boolean  values  from  boolean  operands.  Only 
the  first  operand  is  evaluated  if  this  is  enough  to  determine  the  value  of 
the  expression,  eg  in: 

bl  OR  b2 

b2  is  not  evaluated  if  bl  evali. ates  to  true. 

b ::=  bool  - id[index]  | attribute  | proced-call 
I bool-lit  I bool-expr  | statement 
bool-expr  ::=  b bool-op  b | n rel-op  n | NOT  b 
I ( b ) I expr  = expr 
bool  -op  AND  | OR 

rel-op  ::=  LSS  | LEQ  | EQL  | GEQ  | GTR  | NEQ 
bool-lit  ::■=  TRUE  | FALSE 


2.3  TEXT 

Text  variables  lake  as  values  character  strings  of  arbitrary  length. 
Text  literals  are  indicated  by  enclosure  in  single  quotes.  If  a literal  ’ is 
desired  m a string,  this  is  indicated  by  two  consecutive  ones: 

<> 

TEXT  NAME, TAG 

NAME«-’FRANZ  KAFKA’:  TAG^’DON”T  FORGET' 
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text  ::=  text-id[index]  | attribute  | p'-oced-call  | text-literal  | 
statement 

text-literal  :;=  ’ char-string-with-no-single-’  ' 

2.4  VECTORS 

Variables  of  any  simple  type  may  be  declared  as  vectors  with  bounds  from 
1 to  n where  n is  given  in  square  brackets  following  the  name  in  the  declaration 
statement.  Ar  element  of  a vector  is  indicated  by  a subscript  in  square 
brackets,  when  it  can  be  used  in  an  expression.  Arrays  of  more  than  1 d'  nension 
are  not  pi  ovided. 

<> 

TEXT  VECTOR  days[7],months[12]; 

BOOL  VECTOR  gridx[40],gridy[40]; 

gridx[i]<-gridx[i*?'  OR  gricly[i*3  + l]; 
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3 ELEMENTS 

RpprescritatiOM?  of  physical  objects  and  spaces  in  the  data  base  are 
known  as  El.LMt  NTS.  Each  Element  is  delined  by  a set  of  ATTRIBUTES  which 
may  include  bollt  spatial  Attributes  such  as  Shape  and  location  and  non-spatial 
ones  such  as  cost,  density,  color,  thermal  conductivity  etc.  Elements  can  also 
represent  abstract  entities,  such  as  design  goals,  and  peed  not  have  any  spatial 
Attributes. 

One  way  of  defining  an  Element  is  to  enter  its  entire  complement  of 
Attributes.  This  is  known  as  a FORM.  The  other  way  of  defining  a new  Element 
is  io  describe  it  as  a COPY  of  an  existing  Form.  It  often  happens  that  clashes 
of  Elements  exist  that  have  many  Attributes  in  common,  especially  their  Stiape. 
In  th  is  case  it  is  easier  to  define  an  Element  by  exception,  in  terms  of  its 
differences  from  an  existing  Element,  One  Attribute  certain  to  vary  between 
Elements  is  the  location,  A Copy  is  (tefined  by  entering  its  location  and  any 
other  of  its  Attiibutcs  tint  differ  from  the  Form  from  which  if  is  derived.  The 
Shape  of  a Cofiy  is  largely  determined  by  its  originating  Form,  but  may  vary  in 
certain  ways  described  in  Section  3.8.3.  The  Form  can  be  viewed  as  a typical 
exemplar  for  a class  of  related  Elements.  This  organisation  allows  a convenient 
moans  for  describing  many  similar  objects. 


3.1  NAMES  OF  ( EFMliMTS 

A Copy  is  identified  by  adding  a non-zero  subscript  to  the  name  of  the 
Form  from  which  it  is  derived.  The  zeroth  Copy  is  I tie  same  as  the  Form  Element. 

The  name  of  a Form  or  Copy  is  bound,  to  a single  general  description 
throughout  its  life.  While  part  of  Ihe  definition  can  be  modified  if  is  not 
poosiljle  to  subslifulc  a new  definition.  In  contrastf  a name  declared  as  an 
[ I FM[  NT  ran  refer  fo  a Form  or  Copy  record.  The  Fipmenf  variable  can  be  made 
to  refer  to  a new  lecord  simply  by  reassigning  it.  Element  is  tlio  union  of 
Form  and  Copy. 

Similarly  a name  declared  as  an  ITEM  is  a reference  variable  to  an 
Element  or  a Se|  of  Elements.  (Sets  arc  described  in  section  A.)  Item  is  the 
d.ila  type  wliirb  is  the  union  of  Element  and  Set.  It  is  useful  for  operations 
and  procedures  v/iiich  can  operate  on  either  single  Elements  or  collections  of 
tlicm. 

( 

Those  types  can  bo  organized  in  a hierarchical  fashion,  as  shown  below. 
Each  type  can  refer  to  any  of  those  below  it  in  the  hierarchy: 


ITEM 


FORM 


COPY 


FORM 


SET 
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<>  ELEMENT  thing; 
thing<-box[10]; 

ITEM  this,  that,  the.other; 

copy  fornr\-id[index] 

elem  elem-id  j copy  | form  | proced-calt  1 attrit)utfr 
item  item-id  ) elem  | set 


3.2  ATTRIBUTE  DECLARATION 

An  Attribute  consists  of  a name  and  a value.  The  same  Attribute  name, 
eg.  COLOR  or  DENSITY,  may  be  relevant  to  many  di.fferent  Etements,  and  hence 
Attribute  names  are  always  Global.  Some  Attributes  such  as  Shape  and  Location 
are  system  defined.  Further  Attributes  may  be  declared  by  the  user  to  be  of  any 
variable  type  including  vectors,  and  references  to  records.  The  Attribute 
declaration  is  introduced  by  the  keyword  ATTRJB,  but  otherwise  resembles  a 
normal  declaration.  Atiribule  declarations  return  no  value. 


<1>  ATTRIB  TEXT  CaOR,  MANUF,  MATERIAL; 

ATTRIB  ITEM  PARENT, CHILDREN, SIBLINGS; 

ATTRIB  REAL  VECTOR  CofG[3],  LENGTH[4]; 

attribute-decin  ;:=  ATTRIB  basic-decin 

Both  system  and  user  defined  attribute  names  identify  fields  within 
Element  records.  Elements  are  defined  by  assigning  values  to  these  fields, 
either  within  the  Form  definition  itself  or,  as  exceptions,  within  the  Copy 
record  All  Copies  of  a Form  have  the  same  set  of  Attributes. 


3.3  FORM  CLFINITIONS 

Each  Element  is  defined  through  a Form  or  Copy  declaration.  A Form  is 
defined  by  a Form  procedure  or  a Form  definition  block.  A Form  definition  is 
enclosed  by  the  brackets,  BFORM  and  END  or  { and  },  which  are  equivalent.  It 
contains  a set  of  one  or  more  Attribute  assignments,  separated  by  ";"s.  Each 
assignment  consists  of  an  Attribute  name  which  defines  a field  of  the  Form 
record  of  a given  type,  and  an  expression  with  matching  type,  whose  value  is 
used  to  initialise  the  field.  The  Form  definition  can  also  contain  an  existing 
Form  name  or  procedure  call  that  rj.urns  a Form,  fhe  Attributes  defined  in 
these  are  added  to  the  current  Form  and  thus  Forno?  ta”  be  defined  hierarchically 
in  terms  of  other  Forms.  Attributes  already  in  the  Form  being  defined  and 
existing  within  the  named  Form  are  ignored,  while  all  other  Attributes  in  the 
named  Form  are  added  to  the  one  being  defined.  After  'definition,  however,  all 
the  Attributes  are  conceptually  at  the  same  level  within  the  new  Form,  and  can 
be  accessed  directly  within  it.  One  restriction  is  that  no  Form  can  contain  two 
Attributes  with  the  same  name.  The  value  of  a Form  bind'’^  is  the  new  Form. 

<>  An  Oaken  beam. 

ATTRIB  TEXT  COLOR,  I ATERIAL;  ATTRI3  REAL  Dt^  fi 
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FORM  BEAM  = BFORM 
MATERIAL»-’Oak’; 

DENSlTY»-0.532; 

CUBOIO(  2.5, 1,3);  !procedure  caHI  defining  a 

END: 

FORM  NEWBEAM  = {COLOR-’white’;  BEAM} 


<>  A specification  for  an  office  work  area  Ipr  one  person: 

ATTRIB  TEXT  TITLE,  NOTES; 

ATTRIB  REAL  AREA,  SHELFLENGTH,  DESKFT,  FILESPACE; 
ATTRIB  BOOL  PHONE; 

FORM  WORKSPACE  = 

{TlTLE^-’secretary’; 

AREA«-25:  SHELFLENGTH«-15;  DESKFTe-5;  FILESPACE»-3.25! 

PHONE«-TRL)E;  NOTES<-’Likes  green  wallpaper’  ); 


form-binding  FORM  name  - form-defn 
form  = form-id  | proced-call  | form-defn 
form-defn  "|"  r.lalemeni  {;  statement}  ”}" 

) BFORM  statement  {;  statement}  END 

A statement  in  the  context  of  a form  definition  block  can  be 
an  attribute  assignment,  or  have  the  latter  embedded  within 
them. 

altrib-assign  attrib  •-  expr  | shape-spec  | statement  1 form 


3. A LOCATION 

Location  is  a system  defined  Attribute  that  must  be  specified  for  each 
Copy  of  a Form.  It  may  he  specified  in  world  co-ordinates  or  relative  to  the 
origin  of  any  existing  Element.  This  location  is  defined  by  6 numbers  - 
denoting  the  X,  Y and  Z co-ordinates  and  rotations  in  degrees  round  these  axes. 
The  rotation  is  performed  successively  round  the  X,  Y and  Z axes  in  that  order, 
prior  to  the  translation  of  the  Shape.  These  fields  within  the  Location 
Attribute  can  be  viewed  as  subattributes . and  have  system  defined  names  for 
accessing  them.  They  are: 

CX,CY,CZ  the  three  translation  values  defining  an  offset. 

AX,AY,AZ  the  three  rotation  values  defining  a orientation. 

Locations  will  be  entered  very  frequently  and  so  their  syntax  has  been 
designed  with  conciseness,  in  mind.  A location  may  be  specified  as  relative  to 
an  existing  item,  introduced  by  "ifs"  or,  if  this  is  omitted,  as  relative  to  the 
co-ordinate  origin  (absolute.)  The  offset  and  rotation  are  each  specified  by  up 
to  3 numbers,  introduced  by  "\"  and  respectively.  Either  or  both  may  be 
omitted.  Any  numbers  omitted  default  to  zero. 

<> 

\ 10,20,30  «90,0,90 

\10  *90,45  is  equivalent  to  \10,0,0  *90,45,0 
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\25,20  is  equivalent  to  \25,20,0  #0,0,0 
#180,90  is  equivalent  to  \0,0,0  #180,90,0 

(TO  MATCHBOX[5]#0,20  is  a location  relative  to  MATCHB0X[5] 

location  :;=  [(FD  copy ][offset][rotation], 
offset  ::=  \ triad 
rotation  ;:=  # triad 
triad  ::=  n (,n  [,n]] 


3.5  COPY  DEFINITION 

A Copy  is  named  by  giving  an  existing  Form  with  a new  subscript.  The 
subscript  may  be  specified  by  the  user  as  any  integer  not  yet  used.  If  it  is 
omitted  the  system  supplies  in  default  the  integer  succeeding  the  current 
highest  subscript.  The  Copy  definition  is  enclosed  between  { and  },  and  its 
first  part  specifies  a location.  The  value  of  a Copy  definition  is  the  Element 
defined. 

<>  COPY  B0X[1]  =■  {\20,30, 100); 

COPY  BOX  = (\100  #0,180}; 

COPY  BOX  = {fD  WIND0W[2]  #180,90); 

The  Form  defines  the  allowed  set  of  Copy  Attributes  and  their  default 
values.  For  all  but  the  Shape  these  values  may  be  overwritten  within  each  Copy. 
In  this  case  the  Copy  definition  includes  the  appropriate  Attribute  assignments 
after  the  location  specification. 

oCOPY  BOX  = {\  10,10  #0,90;  COLORr-’blacK’;  LENGTt<»'2.2}; 

<>  A procedure  to  create  a row  of  Copies  at  intervals. 

For  the  syntax  of  procedures  definitions,  see  Section  7. 

PROCEDURE  REPEAT  (FORM  f;  ;FR0M  REAL  x,y,z  flV  dx,dy,d2  :TIMES  n>- 
FOR  i FROM  1 TO  n DO  COPY  f «={\x'i-dx*i,  y+dy*i,  z+dz*!}; 

! Use  procedure  to  make  a stack  of  20  boxes. 

RE^’EAT  box  FROM  100,200,0  BY  0,0,20  TIMES  20; 

copy-decin  ;:=  COPY  form  [index]  = copy-defn 

copy-defn  :;=  location  {;  attrib-assign  } 


3.6  ACCESSING  AT-^F'  3UTES 

Attribute  va'ues  may  be  accessed  but  not  changed  outside  of  the  Form  or 
Copy  definition.  They  may  be  used  in  expiessiois  as  a suoexpressiori  c-t  ;i  e 
appropriate  type,  but  they  may  not  receive  assignments,  Ttie  general  syntax  for 
an  Element  Attribute  is; 

attribute  fttrib-id[index]  OF  copy 


<>  shade*-  color  OF  box[l]; 
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If  several  Alfributes  are  to  be  accessed  from  a particular  Form  or  Copy, 
they  may  be  put  inside  a Form  or  Copy  definition  block,  which  has  the  effect  of 
defaulting  the  Form  or  Copy  name  for  all  Attributes  named  within  it.  The 
default  Element  can  be  overridden,  however,  by  using  the  full  Attribute  name, 
eg. 

<>  BOX[l]{length<-heighth+length  OF  box[0])( 

3.7  MODIFYING  AN  ELEMENT  RECORD 

A Copy  or  Form  can  be  modified  using  a syntax  similar  to  that  by  which 
it  was  initially  defined.  New  attributes  can  be  added  to  a Form  by  using  the 
Form  or  Copy  block  structure.  Note  that  certain  Attributes,  such  as  Shape  and 
Vertex  co-ordinates  (see  section  3.8),  that  were  themselves  bound  in  their 
initial  definition  cannot  be  subseqently  modified. 

A new  value  may  be  assigned  to  an  Attribute  of  a Copy  even  if  it  was  not 
originally  defined  as  different  from  the  Form  value,  however  it  may  not  be  given 
an  Attribute  not  hitherto  defined  for  the  Form. 

Note  that  assigning  a new  Attribute  value  directly  fo  a Form  will  change 
all  Copies  with  the  default  value  for  that  Attribute,  and  tvfnce  must  be  used 
with  care. 

oATTRlB  TEXT  material; 

FORM  table  = {materiah-'wooci';  color<-’brown’;. 
tabloicl(l,T,0,b)  } 

COPY  tablc[l]  =•  (\250,350;  materialr-’steel’} 

tablefl]  = {colorr-’white’}; 

ATTRIB  REAL  cost;  table  = {cost*-75  }; 

fable[l]  = {cost«-'00} 


3.8  SHAPE 

Shape  is  an  Attribute  of  particular  importance  for  designing  physical 
systems.  Shapes  are  represented  as  polyhedra  with  planar  faces.  The  information 
required  to  describe  a shape  is  divided  into  two  parts:  The  TOPOLOGY  and  the 
GEOMETRY.  The  TOPOLOGV  describes  the  adjacency  relations  between  the 
Faces,  Edges  and  Vertices  of  the  polyhedron.  The  GEOMETRY  specifies  the 
relative  position  of  the  Faces,  Edges  and  Vertices,  Thus  a Topology  formats  the 
Geometry  information.  Topologies  may  be  common  to  many  different  Shapes  and 
can  be  entered  independently  from  any  particular  one.  (See  figure  1) 

The  Shape  Attribute  is  associated  with  a Form.  It  is  one  Attribute  that 
may  not  vary  in  the  Copies  of  a Form.  It  consists  of  a number  of  subrecords 
whicli  include  FACES,  EDGES  and  VERTICES.  A Topology  defines  the  number 
and  organization  of  these  subrecords  for  each  Shape.  Each  Face  consists  of  an 
ordered  set  of  Edges.  Each  Edge  contains  two  Vertices.  The  Faces,  Edges  and 
Vortices  are  uniquely  numbered  within  each  Shape  and  this  index  is  used  to 
identify  them. 
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3.8.1  TOPOLOGY 

A Topology  is  a record  type  that  is  definad  independently  of  the 
Elements  it  partially  describes.  A new  Topoiogy  may  bo  constructed  by  means  of 
Euler  operators,  which  combine  new  Vertices,  Edges  and  Faces.  (They  are 
named  after  Euler  who  showed  they  are  sufficient  to  construct  any  legal 
polyhedron.) 

In  order  to  fonstruct  a Topology,  a user  must  declare  a set  of  Faces, 
Edges  and  Vertices  from  which  to  construct  it.  These  records  are  global  and 
always  available  within  a Topology  definition  block.  When  used  to  define  a 
particular  Topology,  however,  they  are  bound  to  that  definition  and  only 
accessible  through  the  Topology  record  they  are  bound  to.  They  are  declared 
using: 

FACE[n]j  EDGE[m]i  VERT[p]; 

where  the  n,m,  and  p denote  the  number  of  new  records  of  each  type  to  be 
created.  As  these  are  used  in  making  ’’’opologies,  the  remaining  are  renumbered  in 
consecutive  order.  If  new  ones  are  added,  these  are  added  to  the  end  of  those 
already  existing. 

The  primitive  operators  for  constructing  Topologies  from  these  records 

are: 

MVE(vl,v2,f)  Make  a new  Vertex  v2  linked  to  vl  on 

Face  f. 

MFE(vl,v2,f  l,f2)  Make  a new  Face  fl  by  linking  vl  and 
v2  on  f2. 

Topology  subrecords  must  be  assigned  in  such  a manner  that  the  final  product 
contains  Faces  and  Vertices  numbered  successively  from  1 to  the  total  number. 
To  assist  in  this  the  following  ooerators  supply  consecutive  numbers  for  new 
faces  and  vertices. 


CVE(vl)  Create  a new  Vertex  linked  to  Vl, 

and  supply  new  vertex  number 
CFE(vl,v2)  Link  vertices  vl  and  v2, 

and  supply  new  face  number. 
CMV(n,vl)  Create  Multiple  Vertices  in  a 
chain  of  n from  vl. 


It  is  possible  to  create  a new  topology  by  modifying  an  existing  one.  A copy  of 
an  existing  one  can  be  set  up  at  the  start  of  a Topology  definition  block  using: 

FETCH  topo  Copies  the  named  topology  to 
be  modified. 


A new  topology  is  constructed  inside  a topology-definition  block, 
delimited  by  0TOPO  and  END.  (As  in  all  record  definitions  { and  } may  also  be 
used  as  delimiters.)  Only  within  this  block  can  the  Euler  operators  be  accessed. 


I 
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Other  statements  can  be  mixed  with  them.  The  value  of  a Topology  definition  is 
the  record  created.  Some  examples  of  Topology  definition  follow: 


oTOPO  PYRAMID  = BTOPO 

FACE[5];  EDGE[8];  VERT[5]; 

CMV(A,l)i  !a  chain  of  4 vertices  from  vertex  1; 

CFE(2,5);  ! Create  the  base  face,  vertices  2 to  5: 

CFE(1,3);  tvertex  1 is  the  apex; 

CFE(1,4): 

CFE(1.5) 

END; 


<>  A procedure  to  make  extrusions  pr  prisfn  topologies,  with  n 
sides.  The  format  of  procedure  declarations  is  descrihetj 
in  Section  7,0. 

TOPO  PROCEDURE  EXTRUDE  (REAL  N)  = 

BTOPO 

FACE[N+2];  EDGE[3*N];  VERT[2tN]; 

CMV(N-I,1);  !the  bottom  ring  of  n vertices; 

CFE(N,1); 

CMV(N,1);  !fhe  top  ring  of  n vertices; 

CFE(N+l,2tN); 

FOR  I FROM  2 TO  N DO  CFE  (1,1+N) 
tjoin  up  top  and  bottom; 

END; 
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geom-c’ecin  geom-type  index 
( geom-type  ::=•  FACE  | EDGE  | VERTEX 
index 

topo-decin  TOPO  name  » topo 
topo  topo-id  ( attribute  | proced-call  | topo-definition 
topo-definition  BTOPO  {geom-decln;}  Iopo-stm1  {j 
topo-stmt  } END 

. topo-stmt  euler-op  | statement 

Any  statement  in  >the  context  of  a Topology  definition  can  contain  Euler 
operations  embedded  within  it. 

euler-op  CFE  n,n  | CVE  n ( MFE  n,n,n  | MVE  n,n,n^  | CMV  n,n 

In  addition  it  is  possible  to  enter  topologies  graphically  on  a 
digitizing  tablet,  representing  them  as  a planar  graph.  Control  is  passed  to 
the  digitizing  program  by  a procedure  ORAWTOPO.  When  entry  is  finished  this 
procedure  returns  as  its  value,  the  new  topology  record.  - 

<>  TOPO  NEWSHAPE  - DRAWTOPO;  ' 


3.8.2  TOPOLOGY  PRIMITIVES 

There  is  a need  to  access  Shape  information  through  a Topology  in 
certain  applications.  See  for  some  examples  Part  ThreCi  Section  3.  The 
following  functions  are  available  for  accessing  topogical  relations  within  a 
Shape. 

E. FACE(f,a) 

returns  the  Edge  (index)  following  Edge  "a"  oh  Face  f.  If  a*0  then 
it  returns  the  first  Edge. 

V.FACE(f,a) 

returns  the  Vertex  following  Vertex  "a"  on  Face  f. 

F. EDGE(e,a) 

returns  a Face  adjacent  to  Edge  e;  one  of  the  two  is  returned  if  a»0, 
the  other  if  a=l. 

V.EDGE(e,a) 

returns  a Vertex  on  Edge  e;  one  if  a»0,  the  other  if  a*l. 

F.VERT(v,a) 

returns  the  next  Face  after  "a"  adjacent  to  Vertex  v, 

E.VERT(v,a) 

returns  the  next  Edge  after  "a"  adjacent  to  Vertex  v. 

Each  operation  returns  the  index  of  the  geometric  primitive  identified. 


■ 
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3.8.3  GEOMETRY 


A Shape  is  composed  of  the  Face,  Edge,  and  Vertex  subrecords.  These 
subrecords  also  have  system  defined  subattributes.  These  attributes  take  as 
subscripts  the  index  of  a Face,  Edge,  or  Vertex.  These  are; 

FACE  LEVEL  ATTRIBUTES: 

FACEA[f]  the  A coefficient  of  Face  f 

FACEB[f]  the  B coefficient  of  Face  f 

FACEC[f]  the  C coefficient  of  Face  f 

FACEK[f]  V the  K coefficient  of  Face  f 

Whenever  these  Attributes  are  accessed,  all  Faces  on  the  Element  are  checked  for 
planarity.  If  they  are  not,  an  error  message  is  returned. 

VERTEX  LEVEL  ATTRIBUTES: 

VX[n]  the  X coordinate  of  vertex  n 

VY[n]  the  Y coordinate  of  vertex  n 

VZ[n]  the  Z coordinate  of  vertex  n 

A Geometry' is  defined  by  the  position  of  each  Vertex.  The  Face  level 

attributes  are  automatically  computed  from  flie  Vertex  information.  A Shape  is 
defined  by  specifying  a Topology,  followed  by  a Geometry,  defined  as  a set  of 
bindings  to  the  vertex  co-ordinates.  Each  X,  Y and  Z co-ordinate  is  bound  to  a 
value  relative  to  the  co-ordinate  origin.  Those  not  specified  are  defaulted  to 
zero.  The  values  can  be  specified  as  numerical  expressions  or  Attributes.  If  a 
coordinate  value  evaluates  to  a single  Attribute  within  the  current  Form  or 
Copy,  the  binding  is  delayed  until  instantiation.  Ufherwise  the  coordinate  will 
be  bound  to  a literal  value  which  is  the  value  of  the  expression  assigned. 

In  assigning  Vertex  coordinates,  lists  of  subscripts  may  be  defined  in 
two  different  ways:  either  a simple  list  of  subscripts  or  else  a consecutive 

range  may  be  defined  by  [nl  TO  n2],  indicating  that  nl,  n2  are  assigned,  and  all 
integer  values  between.  If  nonconsecutive  values  are  desired,  then  [nl,n2,n3  TO 
n4]  or  any  mix  may  be  used.  (In  the  consecutive  form,  nl  < n2  and  in  the 
nonconsecutive  form,  any  order  is  acceptable.) 

<>  The  shape  of  Cheops  pyramid; 

{ SHAPE  = PYRAMID;  VZ[1]-  -tOO; 

VX[2,3]=  -500;  VX[^,5]=  500; 

VY[2,5]=  500;  VY[3,fl]=  -500) 

<>  A shape  definition  procedure  for  a cuboid: 

FORM  PROCEDURE  CUBOID(REAL  L,W,H)  = 

BFORM 

SHAPE  = EXTRUDE(4);  !A  hexahedron  topology: 

VX[1, 2,5,6]=  L; 

VY[2,3,6,7]=  W: 

VZf4  TO  7]=  H; 

END; 

<>  To  build  a pseudo-cylindrical  column  with  N-gon  section. 
FORM  PROCEDURE  COLUMN(REAL  N :RADIUS  R :HEIGHT  H)  - 
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BFORM 

SHAPE  = EXTRUDE(N)! 

FOR  I FROM  1 TO  N DO 
BEGIN 

VX[1,I+N]-  R*SIISKI*360/N): 
VY[U+N]=  R*C0S{I*360/N) 
END; 

VZ[N+1,2*N]=  H 
END; 


' shape-spec  ::=  SHAPE  = topo  {;coord-ass  } 

coord-assign  ::=  coord-id  subscript-list  = h | statement 
A statement  in  the  context  of  a Shape  specification 
j can  contain  coord-assignments  embedded  within  it. 

j coord-id  ::•=  VX  | VY  | VZ 

I subscript-list  "["  sub-range  {.sub-range}  “]"  | "["  ALL  "]" 

rj  sub-range  ::=  n [ TO  n ] 


'! 

i 

' ! 

1 

I 

: I 

! 
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3.8.4  ACCESSING  AND  ALTERING  SHAPE  INFORMATION 

Accessing  geometry  attributes  is  done  in  the  same  way  as  alt  other 
Element  Attributes.  See  Section  3.6.  Modification  of  the  geometry  attributes  of 
an  existing  Element,  however,  is  limited.  While  the  geometry  attributes  may  not 
be  directly  updated,  the  vertex  coordinates  which  evaluate  to  an  Attribute  are 
rebound  each  time  they  are  accessed.  Thus  changing  the  value  of  an  Attribute 
referred  to  by  a geometry  also  alters  the  Shape.  By  Initially  defining  a 
Shape’s  geometry  in  terms  of  a set  of  Attributes,  any  modification  of  a Shape  is 
possible. 

The  Shape  of  different  Copies  of  the  Form  can  be  varied  by  redefining  the 
Attributes  used  in  defining  the  Shape.  Thus  by  having  a unique  LENGTH  for  each 
Copy  of  a Form,  for  example,  each  may  have  a different  Shape. 


<>  ATTRIB  REAL  LENGTH, WIDTH, HEIGHT, NUMATCHES: 
ATTRIB  TEXT  MANUF,  COLOR; 

FORM  MATCHBOX  = BFORM 

MANUF  <-  'SUN  MATCH  INC’; 

COLOR^-'RED’; 

NUMATCHES*- 100.0; 

LENGTH.-5.6: 

WIDTH*-2.6; 

HEIGHT‘-4.825; 

I SHAPE  = HEXA; 

VX[  1, 2,5,6  ] = LENGTH; 

VY{2,3,6,7]  = WIDTH; 

VZ[4  TO  7]  = HEIGHT 
END; 


By  setting  up  a Form  in  the  above  manner,  each  of  its  Copies  may  have  a 
cuboid  shape  with  different  dimensions.  The  initial  values  assigned  to  the 
Attributes  are  the  Form’s  default  values. 


1 


J 


GLIDE 


n 20 


COPY  MATCHB0X[3]  - {\10,10,10;  LENGTH«-7.3i  WlDTH*-3.0}; 

COPY  MATCHBOX  - {\0.5,100,100  n90;  W10TH«-3.0;  LENGTH«-3.95}i 


3.8.5  SHAPE  OPERATORS 

New  Shapes  can  also  be  created  by  combining  existir>g  Element  Shapes,  by 
sticking  them  together  or  cutting  pieces  out.  The  Shape  operators  that  do  this 
have  as  a value  a new  Shape,  consisting  of  a Topology  and  Geometry.  To  be 
saved,  this  Shape  myst  be  assigned  to  a Form.  Again  the  new  Topology  gets  the 
name  of  the  Form  prefaced  by  "S". 

COMB  el  WITH  e2  The  combination  or  union  of  the  shapes. 

LAP  el  WITH  e2  The  overlap  or  intersection. 

CUT  el  FROM  e2  The  difference  of  e2  - el 

The  local  origin  of  any  newly  created  Shapes  is  the  local  origin  of  the 
first  operand.  The  Attributes  of  the  input  Shapes  are  not 
transferred. 

FORM  BLOB  = { MATERIAL«-’steel’; 

COMBINE  D00R[3]  WITH  PIPE[14]  }j 

shape -expr  COMBINE  elem  WITH  elem  1 L^  elem  WITH  elem  | 

CUT  elem  FROM  elem 

The  LAP  operation  is  the  ultimate  test  for  spatial  conflicts.  An 
example  of  its  use  will  be  presented  later. 


3.9  STANDARD  ATTRIBUTES 

There  are  a number  of  standard  system-defined  Attributes  automatically 
associated  with  any  Element.  None  of  these  may  be  explicitly  modified  by  direct 
assignment,  but  are  computed  as  results  of  operations  on  other  parts  of  the 
Element.  They  include: 


NUMCS  the  number  of  Copies  of  the  Form 

TOPOL  the  Topology  used  to  describe  the  shape  of  an  Element 

NUMVERTS  the  number  of  Vertices  in  an  Element 

NUMFACES  the  number  of  Faces  in  an  Element 

NUMEDGES  the  number  of  Edges  in  an  Element 

MAXX,MINX,MAXY,MINY,MAXZ,MINZ 

the  largest  and  least  X,  Y and  1 values 
for  the  vertices  in  this  Element 


It  is  sometimes  clesireable  to  determine  if  a Form  has  a Shape.  This  may  be 
determined  by  evaluating  NUMVERTS;  if  zero,  there  is  no  Shape  associated  with 
the  Element.  Other  system  defined  Element  Attributes  are  defined  in  Sections 
3.9.  All  system  defined  Attributes  for  an  Element  are  listed  in  Appendix  5. 


Figure  1:  Three  level  hierarchy  of  topology, 

geometry  and  location  used  In  GLIDE. 
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4 SETS 

The  Set  record  provides  a way  of  referencing  ruimber  of  Elements 
together  so  that  they  can  be  treated  as  a single  entity,  A Set  can  contain 
Elements  and  also  other  Sets.  Thus  multi-level  hierarchies  can  be  defined.  A 
Set  can  contain  no  more  than  one  reference  to  a Member,  and  attempts  to  enter 
duplicates  are  prevented.  However,  an  Element  may  be  both  a member  of  a Set 
SI  and  a member  of  S2  which  is  also  a Member  of  S2;  GLIDE  will  not  recognize 
this  duplication.  All  operators  which  take  an  Item  for  their  arguments  can 
operate  on  Sets. 

The  members  of  a Set  continue  to  exist  for  as  long  as  they  are  members, 
unless  they  are  explicitly  deleted,  even  after  the  scope  in  which  they  were 
created  as  locals  has  been  exitted. 

A.l  SET  DEFINITION 

A Set  can  be  defined  simply  by  a list  of  Elements  and  Sets  enclosed 
between  BSET  and  END  (or,  again  { and  }).  A list  of  several  Copies  of  the  same 
Form  can  be  specified  concisely  by  listing  the  index  range  after  the  Form  name. 
The  Keyword  ALL  means  all  the  Copies  of  the  Form. 

An  origin  for  rotation  may  be  assigned  to  the  Set  as  the  first  Element 
in  the  Set  definition.  If  omitted  the  default  Is , the  co-ordinate  origin. 

<> 

SET  BOXES  = { MATCHB0X[2]i  SOAPBOX[l,3,7]i  BOX[l  TO  25,27,30]}; 
SET  TRASH  = [\10,10,10;  SOAPBOX[2,A];MATCHBQX[4  TO  17]  }; 

set-defn  "{"[location  ;]  copy-range  {:copy-range}  "J“ 

I BSET  [location  ;]  copy-range  {;copy '■range]  END 

copy-range  set  1 form-rid  [subscript-list]  | 

set-id[subscript-list] 
set-binding  ;:=  SET  name  = set 

set  set-id[index]  | attribute  | proced-call  | set-defn  1 
set-expr 


A. 2 COPYING  A SET 

It  is  possible  to  create  Copies  of  a Set  at  different  locations  in  the 
same  way  as  Copies  of  a Form.  They  are  similarly  identified  by  subscripting  the 
name  of  the  original  Set.  Again  the  subscript  may  be  specified  by  the  user  or 
supplied  by  the  system. 

In  contrast  to  the  Form,  there  are  no  consistency  conditions  on  the 
Copies  of  a Set.  Any  Set  of  Set  Copy  may  be  composed  of  any  Items.  Copies 
may  vary  in  a free  way  from  the  Sets  they  are  initially  made  from. 

<>  COPY  BOXES[l]  - |\  100,0,  100); 

set-copy-decin  !:■»  COPY  set-id  [index]  - "{"location"}'' 
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4.3  ACCESSING  A MEMBER  OF  A SET 

The  nth  member  of  a set  may  be  accessed  thusi 
MEM[n]  OF  set 

This  is  the  nth  member  at  the  top  level  of  the  Set  rather  than  the  nth  element 
going  through  subsets  recursively,  hence  it  may  be  an  Element  or  another  Set. 

4.4  MODIFYING  SETS 


II  is  possible  to  modify  single  Elements  within  Sets  in  the  usual  way, 
by  individually  altering  their  location  or  other  Attributes.  It  is  also 
possible  to  insert  and  remove  members  of  a set  with  standard  functions  PUT  and 


PUT  item  IN  set 
TAKE  item  FROM  set 

TAKE  gives  an  error  message  if  the  Element  is  not  in  the  Set. 


Note  that  Copies  are  made  from  the  original  Set-fbrm  as  it  is  at  that 
time,  but  subsequent  alterations  to  the  firM  Set  will  NOT  affect  any  Copies 
previously  derived  from  it. 

4.5  STANDARD  SET  FUNCTIONS 

NUMMEMS  set  gives  the  number  of  members  of  the  Set. 

ATOM  item  is  a boolean  function  which  returns  TRUE  if  the  Item  is 
actually  a single  Element. 


<>  Examples: 

procedure  to  test  if  a set  contains  an  Item: 

BOOL  PROCEDURE  MEMBERf  ITEM  E;  :IN  SET  S)  - 
BEGIN 

FORALL  m IN  S DO  IF  m EQL  E THEN  RETURN  TRUE; 

RETURN  FALSE 

END; 


procedure  to  create  union  of  two  sets: 
SET  PROCEDURE  UNIONfSET  SI,  S2)  «= 
BEGIN  ITEM  S;  S^{}; 

FORALL  m IN  SI  DO  PUT  m IN  S; 
FORALL  m IN  S2  DO  PUT  m IN  Si 
S 

END: 

! Set  difference: 

SET  PROCEDURE  DIFFfSET  S1,S2>- 
BEGIN  ITEM  S;  S*-{}; 

FORALL  m IN  SI  DO  PUT  m IN  si 
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FORALL  m iN  S2  DO  IF  MEMBER  m IN  SI  THEN  TAKE  m FROM  S; 
S 

END-, 

Procedure  to  enter  attributes  in  inverted  list  form, 
so  that  all  Elements  with  a particular  Attribute  may  be 
accessed  directly; 

PROCEDURE  COLLECT(ATTRIB  SET  ATT;  :IN  ELEMENT  BODY;  :IS  SET  VAL)  - 
BEGIN 

BODY  = (ATT  VAL}; 

PUT  BODY  IN  VAL; 

END; 


5.1  MOVE  OPERATIONS 

The  relative  placement  of  Items  in  space  is  accomplished  with  MOVE.  It 
rotates  an  Item  about  its  local  origin,  first  about  the  X,  then  the  Y then  the  Z 
axes,  then  translates  the  Item,  either  in  absolute  co-ordinates  TO  a new 
location,  or  relative  to  its  current  location  BY  an  offset.  Thus  these  two 
statements  are  equivalent: 

oMOVE  BEAM[15]  TO  BEAM[15]  \25,25; 

MOVE  BEAM[15]  BY  \25,25; 

move  ::=  MOVE  item  TO  location  | MOVE  item  BY  location 

The  origin  for  rotation  of  an  Element’s  Shape  can  be  moved  by  the 
operation  MOVEO.  The  relative  origin  for  rotation  of  Copies  is  an  Attribute  of 
the  Form  and  so  Copies  of  the  same  Form  cannot  differ  in  this  respect.  Thus 
MOVEO  can  apply  to  Forms  and  Sets,  but  not  to  their  copies. 

MOVEO  item  BY  offset 

A special  form  of  MOVE  operation  is  the  negation  of  the  transform, 
reverting  the  Shape  to  its  location  at  the  origin.  This  location  is  particularly 
useful  for  detailing  operations.  It  consists  of 

ORIGIN  item 

To  move  an  Element  back  from  the  origin  to  its  world  location,  NORIGIN  item  is 
used.  Notice  that  unintended  use  of  this  operation  can  result  in  permanent 
misplacement  of  an  Element. 

5.2  SEARCH  OPERATIONS 

This  standard  function  returns  the  Set  of  Elements  (possibly  empty) 
which  overlap  or  are  contained  within  the  specified  Element. 

FINDLAP  elem 

The  use  of  the  Findlap  function  is  important  for  finding  spatial 
conflicts  and  for  determining  topological  relations  between  Elements.  The 
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routine  below  indicates  how  these  issues  might  be  handled  in  a particular 
application. 

procedure  for  checking  the  spatial  conflicts  between  one 
Element  and  all  others: 

PROCEDURE  WMAT.OVERLAPSf  ELEMENT  BODY)  - 
BEGIN 

SET  SS  - FINDLAP  BOOYi 
WRITE  ’These  elements  overlap  it: 

FORALL  TEMP  IN  SS  DO 
BEGIN 

FORM  INTER  = {SHAPE  =>  LAP  B00Y,TEMP}i 

IF  NUMVERTS  OF  INTER  NEQ  0 THEN  WRITE  TEMPi 

END; 

END; 


•5PSP" 
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There  is  no  GO  TO  statement.  All  changes  in  flow  of  control  are 
achieved  by  conditionals,  loops,  procedure  calls  and  the,  EXIT,  LEAVE  and  RETURN 
escape  statements. 

control-statement  conditional  | loop  t escape 

escape  leave  | exit  | return 

loop  for-loop  | while-loop  | forall-loop 

6.1  CONDITIONALS  , 

conditional  ::=  IF  b THEN  statement  [ELSE  stalernentj 


With  the  usual  meaning:  The  ELSE  part  can  be  omitted.  The  if  statement  can  be 
used  as  an  expression,  in  which  case  it  takes  on  the  value  and  type  of  the 
statement  which  is  executed,  or  0 or  null  if  the  condition  i$  false  and  the  ELSE 
part  is  omitted.  The  "dangling  else”  ambiguity  is  resolved  by  binding  it  to  the 
most  recent  IF  THEN  clause: 


<>  IF  B1  THEN  IF  B2  THEN  X ELSE  Yj 
is  equivalent  to: 

IF  B1  THEN  (IF  B2  THEN  X ELSE  Y); 
not:IF  B1  THEN  (IF  B2  THEN  X)  ELSE  Y; 


6.2  FOR  L(X)P 

for-loop  ::=  FOR  name  [FROM  nl^TO  n2IBY  n3]  DO  statement 

The  continue  condition  is  tested  before  each  execution  of  t.he  body  and  hence  may 
be  executed  0 or  more  times.  The  name  is  implicitly  declared  as  a number  for 
the  scope  of  the  body  of  the  loop.  The  FROM,  TO  and  BY  clauses  can  each  be 
omitted,  with  the  following  defaults: 

nl  defaults  to  1 

n2  defaults  to  a very  large  number 
n3  defaults  to  1 if  n2>nl  otherwise  -1 

6.3  WHILE  LOOP  . 

while-loop  ::»  WHILE  b DO  statement 

If  b is  true  execute  the  statement  and  repeat  until  b becomes  false. 

6.4  FORALL  L(X)P 

forall-loop  ::«•  FORALL  name  IN  set  DO  statement 


i 


The  name  is  implicitly  declared  as  an  Element  with  the  scope  of  the  loop  body. 
The  block  is  executed  for  each  successive  Element  of  the  Set. 
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6.5  EXIT  FROM  A LOOP 

exit  ::=  EXIT  expression 

This  transfers  control  out  of  the  current  innermost  loop  to  next  statement  after 
the  end  of  the  loop. 


6.6  LEAVING  A BLOCK: 

leave  LEAVE  [expr] 

This  passes  control  out  of  the  inmost  BEGIN-END  block  In  which  it 
occurs,  and  returns  <expr>,  if  any,  as  the  value  of  the  block.  <expr>  must 
match  the  type  of  the  block  if  any. 


7 PROCEDURE  DECLARATION 

<>  REAL  PROCEDURE  MAX(REAL  a.bMF  a GTR  b THEN  a ELSE  bj 


7.1  PROCEDURE  TYPES 

Procedures  may  be  "functions"  in  that  they  return  a value  of  a type 
which  is  specified  in  the  declaration.  The  procedure  type  may  be  any  scalar  or 
record  type,  but  not  vectors  or  routines.  It  is  omitted  from  the  declaration  if 
the  procedure  returns  no  value.  The  procedure  body  is  an  expression  of  the 
same  type  as  (he  procedure,  often  being  a BEGIN..ENO  block. 

7.2  PARAMETERS  AND  METHOD  OF  CALLING 

The  formal  parameters  are  also  typed,  and  must  be^  explicitly  declared  at 
the  beginning  of  the  procedure  definition.  They  can  be  of  any  type  but  cannot 
be  procedures.  Simple  number  and  boolean  type  arguments  are  called  by 
value,  but  all  others  types  are  called  by  referencje,  and  the  global  version 
can  be  changed  within  the  procedure. 

7.3  ARGUMENT  SEPARATORS 

The  parentheses  enclosing  arguments  may  be  omitted  in  both  calling  and 
declaration  of  procedures.  The  separators  for  the  parameters  may  either  be 
commas,  or  they  can  be  symbols  of  (he  same  construction,  as  names.  These  are 
declared  in  the  formal  declaration,  preceded  by  to  identify  them.  This  is 
to  enable  easy  extensions  of  the  language  with  command-style  syntax  for 
non-expert  users.  The  appropriate  choice  of  separators  helps  to  identify  the 
arguments  where  the  procedure  is  called.  If  desired  for  conciseness  commas  can 
always  be  used  in  the  call  statement  even  if  more  expressive  separators  were 


GLIDE 


II  27 


defined. 

< > SQRT  n; 

CUT  Element  FROM  Element; 

MOVE  Element  TO  x,  y,  z; 

REPEAT  Element  BETWEEN  x,  y,  z AND  x,  y,  z TIMES  n; 

7.4  RETURN  STATEMENT 

The  return  statement  gives  control  back  to  the  calling  program,  and 
returns  the  value  of  the  associated  expression,  if  any.  The  type  of  this 
expression  must  be  compatible  with  the  procedure  type.  If  there  is  no  return 
statement  then  the  value  of  the  procedure  is  the  value  of  the  last  statement  in 
the  procedure  body. 


7.5  EXTERNALS 

All  user-def med  names  used  within  the  procedure  must  be  declared  within 
it.  This  includes  names  which  have  already  been  declared  at  the  outer  level, 
and  procedures  whose  type  and  number  of  arguments  must  also  be  declared 
Lisirrg  a similar  syntax  to  the  original  declaration.  These  must  be  declared  as 
external  thus; 

GET  basic -decln 

GET  [type]  PROCEDURE  proced-id 

( type  argl;  : sep  type  arg2;  :sep  type  arg3;...  ); 

When  the  procedure  is  called  the  system  links  all  the  externals  of  the  procedure 
to  global  names,  at  the  same  time  as  it  links  the  formal  parameters  to  actual 
values. 


extern-proced-decin  = GET  proced-hdr-decin 
proced-decin  ::=  proced-hdr-decIn  = statement 
proced-hdr-decIn  :;=  [type]  PROCEDURE  name  [formats] 

formats  ::=  ( basic-decin  { sep-decin  basic  decln)  ) 
sep-decin  ::=  : name  | ; 
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8.  INPUT  AND  OUTPUT 


8.1  ALPHANUMERIC  OUTPUT 


WRITE  expr  [ON  device] 

will  output  the  value  of  the  expression  onto  tl've  device  specified.  The  default 
device  is  the  CRT  diplay.  The  output  may  include  text  (in  quotes)  and  other 
literals,  as  well  as  data  from  the  database.  The  values  of  numbers,  boolean  and 
text  values  are  output  as  literals.  Record  types  are  output  by  listing  their 
names. 


For  more  extensive  and  informative  output  regarding  the  structure  of  a 
file,  the  command 

DUMP  expr  [ON  device] 

is  available.  In  this  case,  record  types  are  output  in  special  formats:  Forms 

are  output  with  all  Attribute  names  and  their  values,  plus  a list  of  all  Copies. 
Copies  are  output  as  a listing  of  all  Attributes,  except  for  its  Shape. 

NEWLINE  [ ON  device] 

NEWPAGE  [ ON  device]  help  to  format  output. 

A space  can  be  simply  output  thus:  WRITE  ’V 

8.2  ALPHANUMERIC  INPUT 

READREAL  reads  in  a number  from  the  default  input  device  in  either  real 
or  integer  format,  returning  a real. 

READTEXT  reads  a line  of  text  up  to  but  not  including  the  carriage 
return,  and  returns  it  as  a text  variable. 

8.3  GRAPHIC  OUTPUT 

Spatial  Attributes,  namely  Shape  and  Location,  of  Elements  can  be  output 
graphically  onto  the  CRT  display  or  plotter.  To  do  this  it  is  necessary  to 
specify  a view. 

8.3.1  VIEW  RECORD 

View  is  a record  type  which  can  be  declared  and  predefined.  A View  is 
defined  in  terms  of  a reference  point,  view  point,  cone  of  vision,  whether  a 
section  is  desired,  and  the  kind  of  view.  Kinds  include  perspective  and 
orthographic.  Sections  are  cut  through  the  reference  point  normal  to  the 
direction  of  view. 


VIEW  plan=(ORTHO  VIF.WPT  0,0,10000} 

VIEW  front.elevation  = [ORTHO  VIEWPT  0,10000,0] 

VIEW  penthouse  - | PERSP  VIEWPT  1245,  2341, 4 10  REFPT  100,0,0  CONE  180) 
view-decin  ::=  VIEW  name  = view-defn 
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view-defn  view-sort  [SECTION] 

[VIEWPT  n,n,n]  [REFPT  n,n,n]  [CONE  n] 
view-sort  PERSP  | ORTHO 


The  defaults  for  omitted  clauses  are: 

Kind  of  view:  Perspective.  Not  sectioned. 
View  point:  1000,1000,1000 

Reference  poipt:0,0,0 
Cone  of  vision:  60  degrees 


8.3.2  DISPLAY  COMMANDS 

Conceptually  all  Items  to  be  displayed  are  entered  into  a Display  Set  by 
the  command: 

DISPLAY  item  [FROM  view  JON  device] 

and  are  immediately  diplayed  from  the  view  specified,  if  any.  Default  view  is 
the  last  mentioned  in  a command.  Default  device  is  the  fast  on  mentioned  (CRT 
or  PLOTTER). 

Similarly,  ERASE  deletes  the  Items  from  view  by  removing  them  from  the 
Display  Set,  eg 

ERASE  item 


r 


(b)  Hierarchical  oreanlzation  of  records  created  in  the  second 
version  of  STUDWALL.  The  first  MLM  of  a set  DLTAIL  is  the 
PAREOT,  all  others  SIBLINGS. 


EXAMPLE  TV;0: 


ADJACEL'CV  MATRIX 


POSSIBLE  lAYOUT 


g1|^|  ^ 
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PART  111:  SOME  EXAMPLE  GLIDE  PROGRAMS 


The  creation  of  a database  describing  a significant  design,  in  almost 
any  field,  will  require  a considerable  amount  of  GLIDE  code,  written  over  long 
periods  of  time.  A faster  design  process  will  depend  on  a library  of  powerful 
Glide  subprocedures. 

In  the  following  examples,  we  try  to  show  how  some  important  design 
issues  can  be  addressed  using  the  language. 

1.  ALITOMATIC  DET/\1L1NG 

Most  organizations  work  out  standard  ways  of  detailing  certain  parts  of 
a design.  These  may  be  large  units  such  as  a hospital  room  or  small  details 
such  as  a joint  or  fitting.  A design  language  should  allow  definition  of  these 
standard  responses  to  a specific  context  and  allow  them  to  be  applied 
automatically.  The  following  procedures  provide  one  example  of  this. 

PROCEDURE  STUDWALLfELEM  B,  STUD,  MAT;  REAL  SPACE)- 

l.This  procedure  details  a rectangular  slab  B as  a stud  wall,  using  two 
predefined  Forms,  STUD  and  MAT.  Copies  of  STUD  are  create  J spaced  SPACE  units 
apart.  The  studs  are  covered  with  a sheet  of  material  MAT  on  each  sides.  The 
procedure  assumes  that  the  original  definition  of  all  wall  Forms  is  a rectangle 
oriented  along  the  X-axis.  The  same  is  true  for  STUD.  MAT  is  expected  to 
include  two  attributes,  LENGTH  and  WIDTH,  which  determines  the  covering  size. 
The  wall  detail  is  centered  on  the  centerline  of  the  original  rectartgle,  B; 

BEGIN 

ATTRIB  LENGTKWIDTH; 

SET  TEMSET; 

REAL  TX,TY,TZ,LEN,HT; 

! Store  a copy  of  B; 

ELEM  BO  4-  COPY  B-{oB); 

! All  attributes  will  refer  to  B 

B - { TX  4-  MINX; 

TY  4-  MlNYj 

TZ  ♦-  (MAXZ-MINZ)/2-1.75; 

HT  4-  (MAXY-MINY)-1.5; 

LEN  4- (MAXX-MINX)  ; 

Lcreate  plate  and  runrwr; 

PUT  COPY  STUD  - {\TX,TY,TZ;  LENGTH4-LEN  } IN  TEMSET; 

PUT  COPY  STUD  - {\TX,HT,TZ;  LENGTH*-LEN  } IN  TEMSET; 

l.create  studs; 

LEN  4-  HT- 1.5; 

TY4-  TY+1.5  ; 

FOR  J FROM  MINX+1.5  TO  MAXX  BY  SPACE  DO 

PUT  COPY  STUD-  {\J,TY,TZ  #0,0,90;  LENGTH4-LEN  } IN  TEMSET; 

Lplace  end  stud; 

PUT  COPY  STUD  - {\MAXX  OF  B,TY,TZ  #0,0,90;  LENGTH4-LEN  ) 
IN  TEMSET; 
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!..attach  surface  materials; 

TZ  ♦-  TZ+3.5; 

B - { LN  4-  (MAXX-MINX);  HT  ♦-  (MAXY-MINY)  }; 

PUT  COPY  MAT-  {\TX,TY,TZ;  LENGTH4-LEN|WIDTH«-HT  } 

IN  TEMSET; 

TZ  4-  TZ-3.5; 

PUT  COPY  MAT-  {\MAXX  OF  B,TY,TZ  •0,180,0;  LENGTH«-LEN;  WIDTH^-HT  } 
IN  TEMSET; 


l.move  rectangle  and  all  its  parts  back  into  location; 
MOVE  TEMSET  BY  eBO; 

DELETE  {B,BO}; 

END; 


Notice  that  the  temporary  set  TEMSET  that  groups  all  new  elements  allows 
them  to  be  moved  together,  rather  than  one  at  a time.  At  the  end  of  the 
procedure,  B is  deleted  from  the  database.  This  procedure  is  facilitated  by  the 
ORIGIN  operation  and  the  MIN  and  MAX  attributes. 

This  detailing  procedure  is  easily  extended  so  as  to  allow  maintaining 
the  hierarchical  relations  between  sets  of  Elements.  That  is,  instead  of 
deleting  the  original  rectangle,  a designer  may  wish  to  retain  it,  in  that  it 
has  many  important  uses.  First,  it  allows  crude  drawings  without  the  detail  of 
each  stud.  It  also  aggregates  data  for  the  complete  wall.  If  one  desires  the 
structural  or  acoustical  performance  of  the  wall  detail,  the  enclosing  rectangle 
is  an  appropriate  single  unit  for  storing  that  information,  rather  than  with  one 
of  its  components.  The  capability  of  maintaining  hierarchical  relations  is  an 
important  capability  in  design,  whether  manual  or  automated. 

PRCX:EDURE  STUDWALLIELEM  B,  mat,  stud,  REAL  SPACE)- 

L.This  extended  procedure  makes  a Set  DETAIL  with  the  details  in  it. 
The  B has  a set  attribute  KIDS  which  points  to  set  DETAIL  that  contains  the 
elements  which  comprise  it.  Each  component  has  an  attribute  PARENT  of  type  ELEM 
which  points  to  its  parent,  B; 

BEGIN 

GET  SET  DETAIL; 

ATTRIB  ELEM  PARENT,  KIDS; 

ATTRIB  REAL  LENGTH, WIDTH; 

REAL  TX,TY,TZ,LEN,HT; 

! Store  a copy  of  B; 

ELEM  BO  4-  COPY  B-{®B}; 

ORIGIN  B; 


L.create  plate  and  runner; 

B - { KIDS4-COPY  DETAIL-0;  ! creaate  empty  Set 
TZ  ^ (MAXZ-MINZ)/2-1.75; 

HT  4-  (MAXY-MINY)- 1.5; 

LEN  ♦-  (MAXX-MINX)  ); 
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PUT  STUD-{\MINX,MINY,TZ;  LENGTH«-LEN)  IN  KIDS', 

PUT  STUD-{\TX,HT,TZj  LENGTH^-LEN)  IN  KIDS; 

!..create  studs; 

LEN  ♦-  HT-1.5; 

TY  ♦-  TY+1.5; 

FOR  X FROM  MINX+1.5  TO  MAXX  BY  SPACE  DO 

PUT  COPY  STUD-  {\X,TY,TZ  »0,0,90;LENGTH«-LEN}  IN  KIDS; 

TX  ^ MAXX  ; 

PUT  CqPY  STUD  - {\TX,TY,TZ  *0,0,90; 

LENGTH«-LEN  }; 

Lattach  surface  materials; 

TZ  «-  T2+3.5; 

B - { LN  (MAXX-MINXh 
HT  ♦- (MAXY-MINY)  }; 

PUT  COPY  MAT-  {\TX,TY,TZ;  LENGTH«-LENSWIOTH<-HT}  IN  KIDS; 
TX«-MAXX; 

TZ  TZ-3.5; 

PUT  COPY  MAT-  {\TX,TY,TZ  *0,180,0;  LENGTH«-LEN;WIOTH<-HT}  IN  KIDS; 

! Put  in  references  up  the  hierarchy. 

FORALL  E IN  KIDS  DO  E-{PARENT«-B}; 

L.relocate  all  wall  components; 

MOVE  DETAlLtSN]  BY  S BO; 

DELETE  BO}; 

END; 


Access  to  the  components  of  the  wall  B can  be  made  through 
use  of: 

FORALL  S IN  KIDS  OF  B DO  statement 


2.  BUILDING  TOPOLOGICAL  STRUCTURES 

An  important  use  of  GLIDE  is  the  deriving  of  information  needed  for 
analysis  programs.  Of  the  data  that  must  be  generated,  possibly  the  most 
critical  are  the  different  topological  relations  between  Elements,  such  as  the 
structural  grid  or  mechanical  system  tree.  Below,  we  indicate  how  topological 
relations  may  be  computed.  The  capability  developed  is  a general  procedure  that 
generates  anadjacency  matrix  of  all  Elements  within  a Set  that  are  adjacent  to 
one  another.  Thus  if  the  Set  is  of  structiral  Elements,  the  result  will  be  the 
structural  grid.  If  the  Set  includes  all  nxichanical  equipment,  then  the  result 
will  be  a matrix  with  the  tree  of  all  mechanical  equipment  adjacencies. 

Several  service  procedures  are  introduced  first. 

BOOL  PROCEDURE  TOLERANCEfREAL  A,B,C)  - ((A+C  GTR  B)  AND  (A-C  LSS  B)); 
PROCEDURE  EXTFACEfELEM  BODY;  REAL  F;  REAL  VECTOR  C[6])  - 


"WP 
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! This  procedure  returns  the  coordinates  of  , the  enclosing  box 

around  any  faca  and  is  useful  in  determining  (f  two  faces  overlapt 

BEGIN 
REAL  A,B{ 


FORM  BODY  - { B4-A*-V.FACE<F,0); 

C[4>-C[l]  4.  VXtAjj 
C[5>-C[2]  4-  VY[A]; 

C[3]4-C[6]  4-  VZ[A); 

WHILE  ((8  4-  V.FACE(F,B»  NEQ  A)  DO 
BEGIN 

IF  C[  1 ] GTR  VX[B]  THEN  C[  1 ] 4-  VX[B]; 
IF  C[4]  LSS  VX[B]  THEN  q4]  4-  VX[B]j 
IF  C[2]  GTR  VY[B]  THEN  C[2]  4-  VY(B]! 
IF  C[5]  LSS  VY[B]  THEN  C[5]  4-  VY[B]j 
IF  C[3]  GTR  VZ[B]  THEN  C[3)  ♦-  VZ[BJ 
IF  C[6]  LSS  VZ[B]  THEN  qS]  *-  VZ[Bl 
END; 

}5 

RETURN 

END; 


BOOL  PROCEDURE  ADJACENT(ELEM  A,B)  - 

L.this  procedure  tests  the  adjacency  between  elements  A and  B 
and  returns  TRUE  if  any  of  their  faces  are  coincident; 

BEGIN 

EXTERNAL  EXTFACE; 

REAL  VECTOR  AF[6],BF[6i 

FOR  II  FROM  1 TO  (NOFACES  OF  A)  BY  I DO 
BEGIN 

EXTFACE(A,AF); 

FOR  12  FROM  1 TO  (NOFACES  OF  B)  BY  1 DO 
BEGIN 

EXTFACE(B,BF); 

!..use  the  boxtest  to  see  if  faces  overlap; 

IF  AF[1]  GTR  BF[4]  OR  BF[1]  GTR  AF[4]  OR 
AF[2]  GTR  BF[5]  OR  BF[2]  GTR  AF[5]  OR 
AF(3]  GTR  BF[6]  OR  BF[3]  GTR  AF[6]  THEN 
EXITLOOP; 

Ltest  if  the  faces  align; 


TOLERANCE(FACEA(Il) 

OF 

A,FACEA(I2) 

OF 

B) 

AND 

TaERANCE(FACEB(Il) 

OF 

A,FACEB(12) 

OF 

B) 

AND 

TaERANCE(FACEC(Il) 

OF 

A,FACEqi2) 

OF 

B) 

AND 

TOLERANCE(FACEK(Il) 

OF 

A,FACEK(I2) 

OF 

B) 

AND 

THEN  RETURN  TRUE; 
END; 

END; 

RETURN  FALSE 
END; 
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l.this  procedure  builds  an  adjacency  >natri)(,  ADJ,betweeen  the  Elements 
in  the  Set  S.  ADJ  is  the  vector  in  which  adjacencies  are  stored.  N is  the 
dimension  of  ADJ.  It  should  be  equal  to  (NUMEM  * (NUMEM-1))/2|  where  NLA^M  is 
the  number  of  members  of  S; 


r 

I 

i 


PROCEDURE  GRAF(SET  Sj  BCKDL  VECT  ADJ[N])  - 
FOR  II  FROM  1 TO  N-1  BY  1 DO 
FOR  12  FROM  11+1  TO  N DO 
/\DJ[Il*(Il-l)/2+I2]«- 

ADJACENT(MEM(I1.S>,  MEM(12, 


SB: 


3.  ANALYSES  OF  SHAPES 

An  important  aspect  of  some  design  operations  is  the  analysis  of  shapes 
and  the  properties  of  shapes.  Examples  include  computation  of  the  amount  of 
concrete  required  for  a pour  or  the  length  of  run  of  a pipe  or  duct.  These 
operations  require  the  ability  to  access  and  respor>d  to  different  conditions 
encountered  within  the  topology  of  a shape. 

Below,  we  provide  one  meaningful  example,  an  algorithm  for  computing  the 
volume  of  any  shape. 


REAL  PROCEDURE  DET(REAL  T,V1,V2,V3;  ELEM  B)  - «his  procedure  computes  the 
projected  area  of  a triangle  defined  by  the  three  vertex  IDs  V1,V2,V3  onto  the 
plane  denoted  by  XYZ,  where  XYZ-1  means  X,  XYZ-2  means  Y and  XYZ*3  means  Z 
plane.  when  the  points  are  taken  clockwise,  the  area  sign  is  negative} 

BEGIN 

REAL  A; 

B - { IF  (XYZ  EQL  3)  THEN  A«-VXiVl>VY[V2hVX[Vl>VY[V3J- 
VY[V  1 >VX[V2]+VY[V  1 >VX[V3] 

+VX[V2>VY[V3]-VY[V2>VX[V3] 

ELSE  IF  (XYZ  E(3L  2)  THEN  A+-VZ[Vl>VX[V2>VZ[Vl]sVX[V3]- 
VX[V1  ]*VZ[V2]+VXiVl  >VZ[V3) 

♦VZ[V2>VX[V3]-VX[V2]*VZ[V3] 

ELSE  A*-VY[V1>VZ[V2]-VY[V1J*VZ[V3]- 
VZ[V  1 >VY[V2]+VZ[V  1 >VY[V3] 
♦VY[V2>VZ[V3]-VZ[V2>VY[V3»j 

RETURN  A/2 

END; 


REAL  PROCEDURE  AREA(REAL  F;  ELEM  BODY)-  ! this  procedure  computes  the  area  of 
face  F on  body  BODY.  It  chooses  the  plane  of  projection  most  parallel  to  the 
face,  then  corrects  the  projected  area  by  the  cosin  of  the  angle  between  the 
face  and  the  projection  plane; 


BEGIN 
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REAL  A, B,C,D, ANGLE, PLANE! 


!...  compute  area  of  proje  ttioni 

BODY  = {IF  FACEA(F)  GTR  FACEB(F)  THEN  PLANE«-1  ELSE  PLANE«-2! 
IF  FACEC(F)  GTR  (IF  PLANE  EQL  1 THEN  FACEA(F) 

ELSE  FACEB  (F)  ) 

THEN  PLANE«-3i 
B4-V.FACE(F,0)i 
C«-V.FACE(F,B); 

D<-V.FACE(F,C): 

A<-DET(PLANE,B,C,D,BODY)! 

WHILE  BEGIN 
C<-D; 

D«-V.FACE(F,0); 

( D NEQ  B ) 

END 

DO  A4-A+DET(PLANE,B,C,D,B0DY); 

!...  compute  angle  of  projection; 

B*-FACEA(F)*FACEA(F)+FACEB(F)*BACEB(F)+FACEC(F)*FACEC(F)i 
IF  PLANE  EQL  1 THEN  D«-FACEA(F)  ELSE 

IF  PLANE  EQL  2 THEN  D «-  FACEB(F)  ELSE  D FACEC(F); 
ANGLE«-D/(SQRT(B))}i 
RETURN  A/ANGLE 
END; 


REAL  PR(XEDURE  VOLUME(ELEM  B)  - 
! this  procedure  computes  the  volume  of  element  B; 
BEGIN 

REAL  DIST,J,AREAl,VOL,Vi 
V«-0: 

VX[V]vVY[V]^VZ[V>-0: 

AREAl«-0;  VOL«-Oi 


FOR  J FROM  1 TO  NUMFACES(B)  DO 
B - { DIST*-FACEK(J); 
AREAl»-AREA{J,B)i 
VOL«-VOL+(DIST*AREA)}! 
RETURN  VOL/3 
END; 


In  the  examples  provided,  we  have  attempted  to  indicate  the  kinds  of 
design  operations  easily  defined  within  GLIDE.  The  full  extent  of  the  strengths 
and  weaknesses  of  the  language  will  only  be  known  after  extensive  experience 
with  this  and  other  design  oriented  languages. 
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APPENDICES; 

APPENDIX  1 BNF  Conventions  used: 

1.  Non-terminal  symbols  are  represented  by  single  or  hyphenated  words  in 
lower-case,  without  the  <>  delimiters. 

eg  statement,  proced-call,  form-defn 

2.  Terminal  symbols  (keywords)are  in  upper-case:eg;  IF,  THEN,  BEGIN,  or  are 
special  characters  :,  ♦,  +,  <,  ! 

3 In  the  BNF  the  symbol  "name"  is  used  to  signify  a hitherto  undeclared  name,  to 
be  used  in  a declaration,  or  a name  of  any  type.  Once  they  have  been  declared, 
names  of  various  types  are  referred  to  thus: 

num-id  bool-id  text-id  topo-id  form-id  item-id  set-id  view-id 
rojtine-id  command-id  attrib-id  elem-id 


4.  I as  usual  seperates  alternative  strings. 

eg  X ::=  a |b  c I d 

5.  [ ] enclose  optional  strings 

eg  a ::=  b[c]  means  a ::=  b | b c 

6.  { } enclose  strings  repeated  0 or  more  times. 

eg:  a ::=  b {c}  means  a ::=  b | a c 

7.  Literal  terminal  symbols  {}[]  occurring  in  the  syntax  are  enclosed  in  " " to 
distinguish  them  from  the  meta-symbols  defined  above. 

8.  Certain  parts  of  the  syntax  are  highly  context-dependent.  For  example  a 
statement  within  certain  definition  blocks  can  contain  certain  operations  which 
are  illegal  in  other  contexts.  Such  a context  is  valid  no  matter  how  deeply  a 
statement  is  nested  inside  the  definition  block: 

A Euler  operations  can  only  occur  within  a Topology 
definition  block. 

B Attribute  assignments  can  only  occur  within  • Form  or  Copy 
definition  block. 

C Co-ordinate  bindings  can  only  occur  within  a Shape 
definition  block. 

D In  almost  all  contexts  an  expression  must 
be  of  a particular  type,  eg  the  operands  of  an  assignment 
must  match.  In  some  cases  this  constraint  is  not  inherent 
in  the  syntax  as  specified  in  the  BNF,  but  merely  noted 
alongside. 
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APPENDIX  2:  TABLE  OF  INFIX  OPERATORS  WITH  PRECEDENCE. 
Preced.  Operators 


1 

2 

3 

A 

5 

6 
7 


OR 

AND 

LSS  LEO  NEQ  EQL  GEQ  GTR 
+ - 

* / 

t OF 


APPENDIX  3:  FIESERVED  WORDS  AND  SPECIAL  SYMBOLS. 


!*&’(  )-\®{  }[]  + *!:.,/- 

AND  OR  OF  FOR  FORALL  WHILE  IF  BEGIN  END  BTOPO  BFORM  BSET  RETURN  EXIT  DELETE 
SHAPE  PROCEDURE  GET  GLOBAL  ATTRIB  TOPO  FORM  COPY  ITEM  ELEM  SET  REAL  BOOL  TEXT 
VIEW  ALL  FROM  TO  BY  DO  THEN  ELSE  ORTHO  PERSP  VIEWPT  REFPT  CONE  SECTION 


APPENDIX  A:  STANDARD  FUNCTIONS  AND  ATTRIBUTES. 


Standard  attributes: 


SHAPE  TOPOL  VX  VY  VZ  CX  CY  CZ  AX  AY  AZ  NUMVS  NUMFS  NUMCS  NUMELS  MAXX  MINX  MAXY 
MINY  MAXZ  MINZ  E.FACE  V.FACE  F.EDGE  V.EDGE  F.VERT  E.VERT  FACEA  FACEB  FACEC  FACEK 


Standard  functions  and  operations: 

MOVE  MOVEO  ORIGIN  NORIGIN  CMV  CFE  MVE  MFE  FETCH  CLOSE  COMBINE  CUT  LAP  FINDLAP 
WRITE  DUMP  NEWLINE  NEWPAGE  READREAL  READTEXT  MEMBER 


i 

i 


